Comment by elmo2you | Hacker News Reader

Comment by elmo2you | Hacker News Reader

Parent Full thread

I will have to agree with this. Until I started working with Erlang/Elixir, I would probably have agreed with the OP article instead. Or at least its title, for reading about concurrency problems has become rather obsolete (for me).

For years, I certainly made my own share of concurrency horrors, in everything from C and Python to Java and JS. Eventually I (sort of) got it right in each, mostly by building up experience in approaching it the right way. But it always remained a source of easy to make mistakes (and sometimes near-impossible to solve complexities, with larger systems).

However, since working with Erlang/Elixir, I sometimes wonder what the F#$& I was doing all that time. Many ideas were certainly a bit challenging to wrap my head around at first, but once they clicked there (kind of) was no way back.

This will probably sounds arrogant, and it's okay with me if I get down-voted because of it. But the more I work with Erlang/Elixir (and a few others in the FP field), the more it becomes clear to me how much the languages I used to program in (and their typical challenges), now most of all look like a (rather sick) joke to me. Again, I know this might sound pretentious, if not offensive. But it is sincerely what I feel. In my defense: I'm not some kind of hipster, still wet behind the ears. I've been programming for nearly 3 decades and in well over a dozen different language. I'm one of those kids that were ripping apart assembly code of "protected" games and desktop software, and hacked around on micro-controllers, during the nineties.

While Erlang/Elixir may have shortcomings too (although I personally have not found any), it is one of the best things I've encountered for a long, long time. I'm also charmed by ClojureScript, but for totally different reasons. However, I do like it for when I'm forced to build something more complex for browser/front-end. But that's a whole different story, and not much relevant to this concurrency "issue".

> I will have to agree with this. Until I started working with Erlang/Elixir, I would probably have agreed with the OP article instead. Or at least its title, for reading about concurrency problems has become rather obsolete (for me).

That summarizes the problem with most of the articles and discussions on concurrency. People talking past each other because those who don't do much concurrency, especially complex concurrent software, haven't reinvented Erlang yet and don't understand what the fuss is about, and those who do can't explain in relatable terms how the actor model helps them organize concurrent code, preserve local reasoning, abstract, compose it, tolerate faults, etc. and eventually they stop bothering and so poor concurrency articles and comments continue to dominate the infospace.

One thing to realize here though is that this isn't the language that is solving your problems here, it is architecture and methodology, probably combined with being able to leave some performance on the table.

Libraries and tools could replicate this in C++. A lot of people love erlang/elixir and have success with them, but I think it's a mistake to attribute it to the languages themselves and not the beam VM + the ecosystem around it because it misses the deeper understanding of concurrency techniques that work.

I get what you’re saying but it’s not fully right. In c++, the language allows you to have infinite loops. In erlang/elixir you can’t - you need to do recursion instead. This language feature makes sure that one piece of code doesn’t lock a core indefinitely.

That’s why Java/scala’s akka is crazily complicated. They encourage you to use futures so you don’t lock a core! So suddenly you’re still dealing with concurrency but with even more complicating layers.

Your example has no overlap with what I was talking about.

What you are saying is about iteration in the language and does not have anything to do with concurrency or architecture.

There is also nothing difficult about avoiding infinite loops in C++. There is a for loop to iterate through a data structure, or you just can just make a macro to iterate a number of times. This is not something that would cause anyone to feel like a big problem has been solved. Recursion for iteration only has advantages when compared to loose while loops. Once more structured iteration came about, using recursion for iteration is just an awkward and overcomplicated hack that obscures something simple.

> What you are saying is about iteration in the language and does not have anything to do with concurrency or architecture.

> There is also nothing difficult about avoiding infinite loops in C++.

I don't know how to explain it to you if you think you get it already but you don't. Please come into the discussion with an open mind.

Making sure every library you use won't ever block a core is not trivial. If it's a feature of the platform, then it becomes trivial. On Erlang it's a feature of the platform, in c++ it is not.

Reply on news.ycombinator.com