Oh sorry, ya, your example is what I meant to do—that’s what I get for not copy-pasting from the REPL. It mirrored my Elixir example (as much as you could call that mirroring).
sodapopcan
garrison
It would perhaps be better to describe it as having “copy-on-write” everywhere; it is perfectly fine to pass a reference around as long as you never mutate the thing being referenced - and hey, that’s what immutability refers to 
In practice the runtime passes references around all the time, which is super important for performance. But they are always copy-on-write. Note that we can construct more advanced COW data structures out of the primitives the language gives us. For example:
a = "foo"
b = "bar"
c = "baz"
l1 = {a, nil}
l2 = {b, l1}
l3 = {c, l2}
dbg l3 # -> {"baz", {"bar", {"foo", nil}}}
Those strings and tuples shouldn’t be duplicated in memory. Hey wait a minute, is that a linked list?!
0
LostKobrakai
I wouldn’t necessarily call this “better described” because my argument is exactly that you don’t need to care. For the mental model it doesn’t matter at all when copies are created – as long as they’re created often enough that all intermediate values interacted with remain.
1
lud
This to me does not explain immutability. You can have the same code in any mutable language, as you can write a function that returns an updated copy of the input data. Immutability is not not enforced at the language level but below.
Maybe the best way to learn for people is not to give them explanations but an exercise:
Given that code
a = 1
f.(a)
IO.inspect(a)
Write a definition of the function f so the last line prints “2”. You can use anything you want.
And let them struggle for a while 
doing their research to understand it fully.
1
sodapopcan
That’s because I messed up my example and also that it’s impossible to give an exact reproduction in Elixir just because it’s impossible—moreover, I was no longer talking about rebinding. I was trying to make a point similar to Benjamin’s: in any mutable language, some function can transparently change a data structure out from under you whereas that is just not possible in Elixir, there’s not even an escape hatch.
3
garrison
If you were feeling exceptionally evil you could write a macro which replaces variables with calls to the process dictionary…
Mhm, that’s what I was trying to demonstrate in the third code block. Personally I find thinking of data structures as copy-on-write to be easiest to understand, but everyone learns differently so having as many explanations as possible is always beneficial
2
New2Elixir
lud, no idea how I missed your post before I replied.
OK, so that makes a lot more sense.
I wish that was more clearly explained in Elixir in Action, unless it is explained more fully later on.
1
New2Elixir
Thanks everyone, much clearer now.
It seems as though this also relates to the Style of programming?
I get the impression I am not going to be able to program in quite the same fashion as one might in Python, C, etc?
0
Phxie
Depends how you write code in the other languages you mentioned. It’s not a significant switch if you already write modular function based code in the other languages.
You can do stuff like the below to “mutate” an original value even though you are technically replacing it to align with how you likely code normally.
def update(%{record: record} = assigns, socket) do
socket = socket
|> assign(:flash_map, flash_map())
form_update(Group, record, assigns, socket)
end
Technically the above is same as the below, but on paper in the above you have “mutated” the original socket in an immutable way. The main difference with the below is that you could access the original socket by using socket after the updated_socket has been created. It’s not used in the below, but it’s fairly common in Elixir to take a starting value, and use it multiple times to create new values without changing the starting value.
def update(%{record: record} = assigns, socket) do
updated_socket = socket
|> assign(:flash_map, flash_map())
form_update(Group, record, assigns, updated_socket)
end
If you did the next example however, the original socket will be used, because all thats happening is the value of the socket is being updated, but never assigned to a new immutable value.
Below, the socket is never replaced, by using something = socket, so even though the socket has the flash_map assigned to it, it never actually updates the original socket value.
def update(%{record: record} = assigns, socket) do
socket
|> assign(:flash_map, flash_map())
form_update(Group, record, assigns, socket)
end
With regards to functional programming, most people are likely here because of how simple it is to follow so you will unlikely have many issues.
If you look at the example below it shows a basic functional example. You pass some params, check the values, call a function based on the result, repeat until the flow is complete. Functional programming allows you to break code down into bitesize reusable chunks like the increment_reply_count.
##########################################################
#### Reply Count : Handle | Create | Increment ####
##########################################################
defp create_redix_reply_metrics(key, ancestor_id, parent_id, date) do
case Redix.command(:redix, ["EXISTS", key]) do
{:ok, 0} ->
comment = Replies.get_reply(ancestor_id, parent_id, PhxieScylla.convert_date(date))
if comment do
Redix.pipeline(:redix, [
["HSET", key, "vote_count", comment["vote_count"]],
["HSET", key, "vote_milestone", comment["vote_milestone"]],
["HSET", key, "reply_count", comment["reply_count"]],
# Primary Key Values
["HSET", key, "ancestor_id", ancestor_id],
["HSET", key, "parent_id", parent_id],
["HSET", key, "created_at", date]
])
else
{:error, :no_comment}
end
_ ->
:ok
end
end
#################################
#### Reply Count : Handle ####
#################################
def handle_reply_count(reply_id, ancestor_id, parent_id, date) do
key = "reply:#{reply_id}:metrics"
case Redix.command(:redix, ["HGETALL", key]) do
{:ok, []} -> create_reply_count(key, ancestor_id, parent_id, date)
{:ok, _} -> increment_reply_count(key)
end
end
#################################
#### Reply Count : Create ####
#################################
defp create_reply_count(key, ancestor_id, parent_id, date) do
with {:ok, _metrics} <- create_redix_reply_metrics(key, ancestor_id, parent_id, date) do
increment_reply_count(key)
end
end
###################################
#### Reply Count : Increment ####
###################################
defp increment_reply_count(key) do
Redix.command(:redix, ["HINCRBY", key, "reply_count", "1"])
end
Also, another basic explanation and example of mutable vs immutable:
Mutable = Update Value
Immutable = Replace Value
if x = 1
Mutable:
x + 1 = 2
x is now 2
Immutable:
x + 1 = y
y is used in place of x as a replaced value
When you write functions with immutable values, you basically just create new values each time, whilst keeping the original value intact.
Rather than change the original value, you create an updated copy based on the original value whilst leaving the original value so that it can be used elsewhere in the code.
1
New2Elixir
Thank you very much, that is very useful.
I think you hit the nail on the head with the modular function based code. Its not entirely clear ATM, however it does seem as though FP like this does seem to have the potential to make some things simpler.
Appreciate the info.
0