Erlang doesn't offer immutability. It offers a lack of name rebinding. If you want to see why this difference matters, go learn Elixir, and try creating a tight loop without any recursion during which all you do is reassign the value of a variable a billion times.
Notice the ram usage of the machine go to the moon.
Then there's this thing about immutability being guaranteed by processes. No it isn't, though? You just copy the data and operate on a copy (or a fragment, sometimes, in the case of binaries.) The original can be mutated, and if you've scaled anything in erlang, you've seen this cause a bunch of problems around the array module
Erlang isn't actor model (sometimes you hear it called pi calculus, which it also isn't.) These are things that seem casually, superficially similar to what Erlang is, but then, the whole point of the actor model and the pi calculus is to give mathematical rigor to guarantees that Erlang doesn't offer, and then you've confused yourself into thinking that Erlang has properties it doesn't actually have.
Engineering by failed metaphor is tremendously dangerous, because it makes people feel safe in ways they aren't, and just due to the nature of systems, the way you find out is often under terrible pressure and non-rarely unfixable.
"not ever worrying about or messing up concurrency"
Like. How new do you have to do be to Erlang and Elixir to think that message passing means you can't mess up concurrency?
If you ask a C programmer to name some threading problems, five dollars says one of the first three they name is some variation on lock contention.
Messaging does not solve this. (Arguably it makes it worse, since every blocking process is now effectively a lock, which is a generally discouraged design strategy in most languages but encouraged as a primitive in this language.)
Indeed, just as OO problems got more common in C++ vs C because of how easy OO became to do, and how frequent it became, I actually end up seeing a lot more concurrency related problems in Erlang than in most languages, just because there's a lot more concurrency than in most languages.
And this isn't be complaining about erlang; I love it. But also, if you've just upgraded from bows to rifles, you have to understand that with that improvement will also come an increase in accidental bullet injuries.
Saying you'll never have concurrency problems in erlang is like saying you'll never have allocation problems in C++. It suggests that everything you know about the language is reading chapter three's discussion about how tools are made available to mitigate this (in C++'s example it'd probably be a SFINAE discussion or something naive about automatic deletion, or if it's an old enough document, maybe smart pointers.)
That that tooling exists suggests there's an active problem being actively mitigated, not that the problem is solved in blub and not everywhere else. There's a reason you don't see cut outside prolog.
In order to abuse one of my favorite community metaphors, "the reason footguns exist is that sometimes you actually do need to shoot lots of animal at once; don't take it out of the case unless Dracula shows up, but, in the balance, eventually you'll be glad you know [Burt Gummer](https://www.youtube.com/watch?v=SdwFp2D5Eg8)."
.
> Then you'll wan to do something distributed, and everything you've learnt about single-node development becomes applicable to distributed systems.
This just makes me laugh, sadly.
"Because I passed messages in a message passing language, I'm now ready to write distributed systems" is just the most delightfully naïve claim
There are red flags. Red flags are a thing that exists.
And the thing is, you see them all the time in places you shouldn't. [This is correct](https://martin.kleppmann.com/2015/05/11/please-stop-calling-...) and yet my trainers at two FAANG companies claimed that they had internally solved this at large scale within the company, on down from on high from the biggest people in the space
You see fucking Oracle get that wrong
Like the very first three things you ask about distributed systems are:
1. how well does it tolerate partitions,
2. how well does it perform over a WAN, and
3. did you design for both city loss and provider loss
With erlang, the traditional answers are
1. no-ish (that is, only just barely and by throwing away everything you used to love about the language to get a hokey election system that barely works and seems designed for the explicit purpose of causing merge failures (it's the CVS of rejoins, i swear to your god) )
2. (loud, plaintive sobbing)
3. we stood up three copies of the system, does that count? what do you mean transactional
The people saying that Erlang solves distributed systems are the people who stood up an ejabberd instance on their desktop and one on their laptop and declared themselves the vice president of MS Azure Engineering
like yes, it does get rid of a few problems, and it has some convneiences, but
what would you do if someone told you haskell solved all logic errors? some offered responses include:
1. believe them, drop everything, and make all life a burrito
2. say "wow, this person isn't very good at haskell, are they?"
.
> The synergy between the runtime, standard library and language, backed by the actor model + immutability is a huge productivity win. It's significantly different (to a point where I think it's way more accurate to group Ruby with Go than with Elixir), but, as I've tried to explain, very approachable.
I read this paragraph out loud and suddenly I had two people making toothpaste commercials working for me
I don't understand what happened. Am I a marketer now?
this is pretty abrasive, but it's also 100% correct. before you downvote this you should take the time to investigate the claims it makes and think about whether what you think you know is actually true
i learned a ton about distributed systems in my time writing erlang and elixir, but it was almost always because i was forced into it by misapplying some erlang/elixir feature and backing myself into a corner. the idea that erlang/elixir make concurrency easy is extremely dangerous. what they do is make it accessible. you still need to understand what you are doing
Notice the ram usage of the machine go to the moon.
Then there's this thing about immutability being guaranteed by processes. No it isn't, though? You just copy the data and operate on a copy (or a fragment, sometimes, in the case of binaries.) The original can be mutated, and if you've scaled anything in erlang, you've seen this cause a bunch of problems around the array module
Erlang isn't actor model (sometimes you hear it called pi calculus, which it also isn't.) These are things that seem casually, superficially similar to what Erlang is, but then, the whole point of the actor model and the pi calculus is to give mathematical rigor to guarantees that Erlang doesn't offer, and then you've confused yourself into thinking that Erlang has properties it doesn't actually have.
Engineering by failed metaphor is tremendously dangerous, because it makes people feel safe in ways they aren't, and just due to the nature of systems, the way you find out is often under terrible pressure and non-rarely unfixable.
These "everybody knows" beliefs are really fucking bad. REALLY bad. You can see some examples here: https://aphyr.com/posts/288-the-network-is-reliable
.
"not ever worrying about or messing up concurrency"
Like. How new do you have to do be to Erlang and Elixir to think that message passing means you can't mess up concurrency?
If you ask a C programmer to name some threading problems, five dollars says one of the first three they name is some variation on lock contention.
Messaging does not solve this. (Arguably it makes it worse, since every blocking process is now effectively a lock, which is a generally discouraged design strategy in most languages but encouraged as a primitive in this language.)
Indeed, just as OO problems got more common in C++ vs C because of how easy OO became to do, and how frequent it became, I actually end up seeing a lot more concurrency related problems in Erlang than in most languages, just because there's a lot more concurrency than in most languages.
And this isn't be complaining about erlang; I love it. But also, if you've just upgraded from bows to rifles, you have to understand that with that improvement will also come an increase in accidental bullet injuries.
Saying you'll never have concurrency problems in erlang is like saying you'll never have allocation problems in C++. It suggests that everything you know about the language is reading chapter three's discussion about how tools are made available to mitigate this (in C++'s example it'd probably be a SFINAE discussion or something naive about automatic deletion, or if it's an old enough document, maybe smart pointers.)
That that tooling exists suggests there's an active problem being actively mitigated, not that the problem is solved in blub and not everywhere else. There's a reason you don't see cut outside prolog.
In order to abuse one of my favorite community metaphors, "the reason footguns exist is that sometimes you actually do need to shoot lots of animal at once; don't take it out of the case unless Dracula shows up, but, in the balance, eventually you'll be glad you know [Burt Gummer](https://www.youtube.com/watch?v=SdwFp2D5Eg8)."
.
> Then you'll wan to do something distributed, and everything you've learnt about single-node development becomes applicable to distributed systems.
This just makes me laugh, sadly.
"Because I passed messages in a message passing language, I'm now ready to write distributed systems" is just the most delightfully naïve claim
There are red flags. Red flags are a thing that exists.
And the thing is, you see them all the time in places you shouldn't. [This is correct](https://martin.kleppmann.com/2015/05/11/please-stop-calling-...) and yet my trainers at two FAANG companies claimed that they had internally solved this at large scale within the company, on down from on high from the biggest people in the space
You see fucking Oracle get that wrong
Like the very first three things you ask about distributed systems are:
1. how well does it tolerate partitions, 2. how well does it perform over a WAN, and 3. did you design for both city loss and provider loss
With erlang, the traditional answers are
1. no-ish (that is, only just barely and by throwing away everything you used to love about the language to get a hokey election system that barely works and seems designed for the explicit purpose of causing merge failures (it's the CVS of rejoins, i swear to your god) ) 2. (loud, plaintive sobbing) 3. we stood up three copies of the system, does that count? what do you mean transactional
The people saying that Erlang solves distributed systems are the people who stood up an ejabberd instance on their desktop and one on their laptop and declared themselves the vice president of MS Azure Engineering
like yes, it does get rid of a few problems, and it has some convneiences, but
what would you do if someone told you haskell solved all logic errors? some offered responses include:
1. believe them, drop everything, and make all life a burrito 2. say "wow, this person isn't very good at haskell, are they?"
.
> The synergy between the runtime, standard library and language, backed by the actor model + immutability is a huge productivity win. It's significantly different (to a point where I think it's way more accurate to group Ruby with Go than with Elixir), but, as I've tried to explain, very approachable.
I read this paragraph out loud and suddenly I had two people making toothpaste commercials working for me
I don't understand what happened. Am I a marketer now?