Hacker News new | ask | show | jobs
by weehoo 2054 days ago
I’ve found Elixir (+Erlang/OTP) to have some incredibly powerful primitives that make it fairly simple to develop concurrent programs.

OTP underpins WhatsApp, Facebook Messenger, and Discord. People have been building very cool high availability embedded Linux projects using the Nerves framework. It’s very good for certain types of concurrent programs.

It won’t take over HPC simulation any time soon, but most of us aren’t working at Sandia, Oak Ridge, etc. Its great for systems that should naturally scale out but don’t map naturally to a GPU. For systems that want to scale up but are forced to scale out due to frequency limits, it’s not as good as C++ written with uArch in mind.

1 comments

I like Erlang/Elixir but I still see a lot of code with obvious race conditions.

The difficult part I find with Elixir is that processes have a lot of roles: fault isolation, concurrency, synchronization, garbage isolation, maybe more. I've had projects where it's difficult to line these up - one design would be ideal for fault isolation, but it forces expensive copies to be made, so I can't use that design because it completely tanks performance.

> I like Erlang/Elixir but I still see a lot of code with obvious race conditions.

Race conditions? Are you sure? AFAIK, that's pretty much impossible in Erlang/Elixir.

I do get with what you are saying with the second part of your post. That can indeed become an issue sometimes. Certainly one that I've struggled with myself, especially when things were still new to me.

But in my experiences, all those (apparent) conflicts/challenges can be mitigated/solved with proper architecture. Granted, that takes experience, which not all programmers may have (yet).

At the end of the day, programming is a skill and (inexperienced) programmers can always dig themselves a hole, in any language. Elixir is not a silver bullet, that magically solves problems without having to work (hard) on finding the right solution/architecture for a given (complex) problem. Still, in my experience, Elixir makes large/complex distributed systems, and in particular concurrency, a heck of a lot easier than it used to be (for me).

#jm2c

Anytime the validity of an operation depends upon the state of multiple processes you need to make sure you aren't creating a race condition, and depending upon your solution you might introduce a chance of deadlocks or timeouts.

If it's just 2 processes then it's pretty easy: process 1 asks process 2 to modify itself, then process 1 modifies itself. However, this can lead to deadlocks/timeouts if both P1 and P2 are attempting to perform this operation at the same time.

And once you're into 3 or more processes, message passing as a method of synchronization breaks down.

Ideally you avoid this stuff with your design. But since processes fill so many roles you can't always avoid it.