Hacker News Reader

Comment by chops | Hacker News Reader

Also (unrelated), My favorite quote from the article:

"Race conditions are why sane programmers don’t program with threads or, if they do, they use shared-nothing architecture and pass all communication between the threads through a message queue written by someone who knows what they are doing (if you have to ask, it isn’t you — seriously, multithreaded programming is hard)."

Sounds like an advertisement for Erlang :)

View on HN

You can absolutely have race conditions in Erlang, along with deadlocks too.

Absolutely, but it tends to be significantly rarer, and easier to debug (in part due to tools, in other part due to OTP patterns) than multithreading race conditions.

But yeah you can have race conditions in everything, you can also have race condition in non-threaded evented code (e.g. heavily async javascript client-side code)

Or Go. Though unlike Erlang processes, Go doesn't make mutating shared memory in multiple threads impossible. Go just makes it really easy to never do it.

Or haskell with STM.

Or ØMQ.

We're just starting a new project this week. It's not that complicated in the big scheme of things, but there are several bits of hardware that need to be coordinated which maintain their own state, plus a GUI, logging, and database updates.

We'd initially talked about what modules and what main threads would be needed, but I started getting paranoid.

So we're going to be using the Python multiprocessing library, and ZeroMQ plus JSON for the communication between the parts.

Reply on news.ycombinator.com