Hacker News Reader

Comment by jshen | Hacker News Reader

Concurrency isn’t easy in any language.

That's a point worth emphasizing. Functional programming is advocated as a means of simplifying programming. When you program with pure functions which always return the same results for the same arguments, things become like mathematics, expressions can be simplified and reasoned about. Yes.

But I don't see how such a purely mathematical viewpoint could fit nicely into the real-time world where processes evolve concurrently and can take different times to do things on different executions. In the real world things are mutable, and concurrent programming must take that into account. Therefore it is "complicated".

Erlang comes pretty close to achieving this. When/if people get past the “weird” syntax it’s a very straightforward model that minimizes a lot of the hazards, though locks are definitely still possible.

The actor model struggles when you run up against something that is naturally sequential and the order matters.

If you want a 1000 households to visit a set of shops in a repeatable Random order until the shops runs out of stock, that’s a List sort with a seed and a sequential loop

Make the 1000 households concurrent and sending messages and it becomes a major exercise in clocking, scaling and scheduling.

Erlang processes (Actors) solve this kind of problem naturally, with code that is concise, asynchronous and parallelized. For example, look at solutions for 'Sleeping Barber'. It's possible to write a full solution in <40 SLOC.

Starting 1000 processes is trivial and fast in Erlang. See the first few pages of Joe's presentation from 20 years ago: process creation time ~10us (up to 30k processes); message time ~1us [1]. The code is in his book and the email thread [2]:

[1] https://www.rabbitmq.com/resources/armstrong.pdf

[2] https://erlang.org/pipermail/erlang-questions/2007-July/0280...

It’s rather more tricky than the sleeping barber. It’s more that their are 100 hairdressers, each household has a set of seven of them and each hairdresser only has a fixed amount of hair colour so not everybody will be served, and you need to be able to repeat the visits deterministically based on a random seed so the only whole process is verifiable.

I really like Fred (ferd) Hebert's take on erlang and concurrency and distribution problems (Earlier in the book he points out how concurrency and distribution are a similar type of problem).

https://learnyousomeerlang.com/distribunomicon

> distributed programming is like being left alone in the dark, with monsters everywhere. It's scary, you don't know what to do or what's coming at you. Bad news: distributed Erlang is still leaving you alone in the dark to fight the scary monsters. It won't do any of that kind of hard work for you. Good news: instead of being alone with nothing but pocket change and a poor sense of aim to kill the monsters, Erlang gives you a flashlight, a machete, and a pretty kick-ass mustache to feel more confident

> This is the standard 'tools, not solutions' approach seen before in OTP; you rarely get full-blown software and applications, but you get many components to build systems with. You'll have tools that tell you when parts of the system go up or down, tools to do a bunch of stuff over the network, but hardly any silver bullet that takes care of fixing things for you.

As for the weird syntax, I use Elixir (https://elixir-lang.org/) on the daily and its pretty great. See here for a different write up I did https://news.ycombinator.com/item?id=24173635

If anything I learned from writing concurrent code before, and after doing it in Clojure - when talking about uncomplicated concurrency, you have to begin with immutability. Without immutability by default, that conversation is a non-starter.

That's a fair point. Having said that, it's also interesting to realize that most distributed systems (which are concurrent by their very nature) don't have that luxury. Our micro-services interact with databases, event queues, blob stores etc and each of those external entities is shared mutable state. Furthermore, services can crash at any time and can't start from a clean slate (unlike in-process concurrency which doesn't have to worry about that). My meta-point is that while I agree with your sentiment, the reality of modern day services is that you are _forced_ to reckon with mutable complexity when designing distributed concurrent services (and more and more of us are doing that with the shift to micro-services in the industry)

Reply on news.ycombinator.com