> I haven't thrown any hand grenades over the wall. Overly sensitive Elixir programmers always throw a fit whenever someone says "you know, other tools are available to you too."
I don't think anyone would take issue with your comments if that's how you approached it.
Instead you're being an asshole, and for no reason I can understand. It's not like we're talking politics here...
> I don't think anyone would take issue with your comments if that's how you approached it.
I got voted into the floor for saying "you're a better elixir programmer if you also learn erlang," which is a simple fact.
I do think this. I think that most micro-language communities are bizarrely intolerant of criticism, and unwilling to cope with the idea that everylanguagehasproblems and that you can only get good at a language if you face them with open eyes.
Imagine a C programmer getting offended if you warned someone learning C "by the way, if you're doing string parsing, you're gonna have a bad time."
.
> Instead you're being an asshole
I love how I've given measurable facts and technical claims, and in order to resist, the members of this community are trotting out swearing and insults, then imagining that they've made a valuable case
> I got voted into the floor for saying "you're a better elixir programmer if you also learn erlang," which is a simple fact.
I don't think that's the case. As an active participant in the various Elixir communities, I've found that the general advice is that learning Erlang, while not necessary, is definitely worth it. Many of the community 'members' do or did plenty of Erlang programming, and the stories of all the 'goodies' and how much simpler Erlang can be at times have more than once gotten me to play around with it. I generally find very little hostility between Elixir and Erlang programmers. Far from it.
I also strongly contest that you're just saying "you're a better elixir programmer if you also learn erlang". At best, some of your comments approach the sentiment, but then end with judging the commenter a blub programmer, or something similar.
I can understand if maybe you've had bad experiences with 'micro-language communities' and you're reading that into what Elixir programmers are saying, but by and large I very rarely come across Elixir programmers who thumb their nose at Erlang. More than anything the sentiment is a kind of reverence and maybe even a degree of 'embarrassment' over finding it hard to get over Erlang syntax.
> I do think this. I think that most micro-language communities are bizarrely intolerant of criticism, and unwilling to cope with the idea that every language has problems and that you can only get good at a language if you face them with open eyes.
That's perhaps true, but Elixir is among the few communities where I find much less of that than elsewhere. The forums and slack are rife with day-to-day Elixir/Erlang programmers who lament the lack of static typing, argue about how Phoenix is too magical, and so on. One reason I was drawn to Elixir was precisely the relative lack of "this is the best thing ever and everything else sucks" sentiment that I find in so many other programming language communities.
I was assuming you were just trolling, because it's hard for me to believe that you don't see the discrepancy between what you say you are saying, and what you're actually saying. It's very discrepid!
You've been perpetuating a flamewar in this thread. We don't want those on HN. Please stop, and please don't do it again.
That includes not tossing in swipes like "This just makes me laugh" and so on. Your comments have been provocative to the point of being trollish, as well as outright nasty in places. That's not cool, regardless of how much you know about Erlang.
The original post wasn't just a general statement, it was inflammatory and accusatory. The poster stated that Elixir not only teaches programmers the wrong things, but that it leaves them damaged. Did not give a single example or explanation for their rationale.
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
