[stcredzero]

The one big substantive point was about callback hell. Coroutines and channels are exactly what's needed to solve that. Add in a minimalist language design focus on programming in the large, and you have a prescription for what ails Javascript on large projects.

This doesn't make Go a silver bullet. (So don't make that mistake, please!) It just happens to be the right kind of tool for two of the more salient problems right now.

[andrewvc]

I agree that callback hell sucks, and promises are a vast improvement, but still shitty. Coroutines and channels are not obviously 'just what's needed' in my opinion however.

I think they're part of a larger picture. Mature languages should have multiple concurrency models available for different tasks. Clojure, for instance, supports coroutines, threads, and multiple other flavors of concurrent programming.

There is no silver bullet, polyglot concurrency is the future most likely.

[stcredzero]

> polyglot concurrency is the future most likely.

One kind of "polyglot concurrency" was the precisely problem of the past! In fact Rich Hickey says himself: You can do concurrency in Java with semaphores and such, but you end up doing some sentinel-thing that's somewhat specialized for your particular subsystem. Then you have to interface with this other subsystem...implement this new feature...then several months later you have a bug introduced because these weren't put together correctly.

In a large Clojure project, you should pick a particular way of doing things, then maybe allow a wrinkle or two, then be consistent about it throughout your project, or at least in that subsystem. Maybe you make your entire model an Atom and have a few FIFO queues for information coming in and going out? What you don't want to do then is to mix in transactional memory or Agents. Otherwise you can find yourself back in the "polyglot" mode of Java. With Go, you have a few flexible primitives from which to produce concurrent systems, but the same thing goes here too. You need to pick a few patterns and stick with them. Otherwise you can make your life much harder.

However, when you start going parallel, whatever you have chosen can go pear-shaped for some hard to fathom reason. Go is no better in this regard.

[andrewvc]

Agreed that you shouldn't mix concurrency models excessively, but many problems do call for a mix. I don't think Rich was referring to what I am. He was talking about the trouble composing Java concurrency using locks and such, which is just hard.

On the other hand with clojure, a standard mix is to use non blocking IO to multiplex a large number of connections, then delegate work to a threadpool (using clojure refs/atoms etc.). Such a system has a much smaller chance of deadlocks and other issues.

A great example of polyglot concurrency is the clojure reducers framework that lets you delegate work to a fork/join pool. Most people don't need it, but it's nice to have a safe, seamless interface to such an advanced concurrency tool.