Hacker News Reader

Comment by andrewvc | Hacker News Reader

This is why clojure is awesome. It's a nice enough language, but where it really shines is that it gives you pretty much every concurrency tool under the sun. You have the entirety of java.util.Concurrent + all the cool clojure tools like agents,core.async,atoms,transactional memory, etc.

Can you shoot yourself in the foot here? Sure. But you also have the right tool for the right job if you know what you're doing.

View on HN

Parallel concurrency is the Great White Whale of our time. Languages like Python and Ruby give you a toothpick to hunt with. Java gives you a letter opener. Go gives you a decent bowie knife. Clojure gives you something like a proper harpoon. But something eventually has to come along at some point to make it possible to not have to take down Moby Dick in the first place. I don't know what that is but I'd love to see it.

There is quite simply no argument that Java doesn't provide better complex concurrency support than Go. You can argue that the golang defaults are better, but there is nothing you can do in go that you can't do in Java and quite a bit the other direction that reverts to "program C with FFI".

Using that argument you can assert that all languages are equal in every aspect. So, not a useful argument.

But something eventually has to come along at some point to make it possible to not have to take down Moby Dick in the first place.

How about something that was built on the design principles of Erlang, but with much faster execution speeds?

Such as?

I think this holds true for only Haskell and Clojure. You're missing something important everywhere else (especially STM).

One nice thing about STM in Haskell is that the type system will help prevent you making mistakes. I've benefited from the types tracking how I'm creating and combining database transactions, which makes it easier to compose them into one big DB transaction from smaller ones.

I have never seen Refs(STM) being used in a Clojure open source project, looks like they are great in theory but in practice they are another story, on other hand, core.async is much more prevalent, I do hear a lot about the use of Haskell's STM thought.

Yeah I think there is a very real cost to going the STM route when you can have arbitrary side-effects, so it's a lot harder for that tradeoff to be worth it than in haskell. That's not to say there aren't any downsides to a language that prevents uncontrolled side-effects, but being able to make more guarantees is one of it's greatest upsides.

In your run of the mill webapp you rarely have state outside the db and caches. What little you have can often be modeled with a single agent or atom. So no need for refs.

What you do have in webapps is synchronization between concurrent processes. For that the STM primitives don't offer much. The core.async on the other hand is a great fit.

I used to be a big proponent of Clojure because of the tooling and solid library support (what you mentioned, but also persistent immutable data structures). However, I never got over the runtime errors that kept cropping up due to a dynamic type system. So many typos, nil propagation, subtly incorrect function application, confusing macros etc.

Reply on news.ycombinator.com