Hacker News Reader

Comment by rubiquity | Hacker News Reader

1) Learning different programming languages is one really good way to grow as a programmer.

2) The web is just one of several mediums for delivering content these days.

3) Node.js has a highly suspect concurrency model that might not be suitable for all the various types of programs you could be building.

View on HN

Why highly suspect ? We know and use cooperative concurrency since decades.

Agreed on the "not suitable for all" but no one said that.

Cooperative concurrency is fine and a lot of languages use cooperative concurrency just fine. The issue with Node is that it completely ignored the multicore reality that we live in. Everyone argues that multithreading is so complex, and it is unless you have the right abstractions. But what is guaranteed to always be complex is single-threading with process forking. As soon as you want to communicate between processes, and you will want to communicate between processes, you now have to implement IPC. In come the message queues... that is once you pick which message queue to use.

We've also been using event-driven IO for decades and Node is the only modern run-time to ignore the obvious perils of evented IO. Instead of doing what languages like Go and Erlang did, which is have event loops in the run-time that are completely transparent to the developer, Node pushes the evented IO right into the application developer's face. Are there remedies for writing good evented code? Absolutely. But why should application developers need to be schedulers in the year 2014?

The stuff you were saying about forking, IPC... it made me giggle because I just wrote a midterm on these concepts last night :)

Thanks.

Erlang seems interesting, would you mind expanding on Erlang or GO?

Everything in Erlang is asynchronous and non-blocking but this is almost completely transparent to the programmer. When you start an instance of the Erlang VM it spawns as many threads as you have CPUs and a thread for an event loop. Each thread can have thousands of Erlang processes (Erlang's unit of concurrency is called a process) executing. Inside of the thread is an Erlang scheduler that allocates execution time to each Erlang process using a technique known as reduction counting.

Erlang also has great features for distribution. Communicating with processes that live in another Erlang VM node is also transparent. It's debated whether this is a good thing or not because some people think communicating over the network shouldn't be transparent due to partitioning, but in a lot of Erlang programer's experiences this is a wonderful feature.

The result of all of this is that the Erlang code you write looks synchronous but is executing concurrently. You have both CPU concurrency and IO concurrency. The Erlang VM takes care of most of the nasty bits of asynchronous code, which is what a good language run time does for you.

Thanks,

Where is Erlang used predominately? Is it a "good" solution for web development (if that's even possible)?

Jose Valim, a RoR developer, created a language (Elixir) just for your use case. Go have a look!

Reply on news.ycombinator.com