Comment

Comment by jerf

I don't know why actors are on his list, but speaking from my own experience, I think actors are one of those cases where some languages (Erlang in particular) got some stuff accidentally correct because they implemented actor-like stuff, but it wasn't necessarily the actors that did the good stuff. Go's runtime is theoretically somewhat similar here, and despite years of work in Erlang, I almost immediately found myself preferring to work in a relatively conventional imperative language where concurrency was cheap, rather than "an actor-based language".

Perhaps the core problem is that no matter how you slice it, the nature of being an actor-based system means that cross-actor calls are simply more runtime and cognitively expensive than a conventional function call, and across the sum total of the system, that ends up adding a lot of drag. It may be the case that "cheap concurrency" added value, and actors actually net removed value, but the sum total was positive in the end. (I'm spitballing a bit here, to be clear.)

To really see the cheap concurrency in play, Haskell is a great place to play. It has a ton of mechanisms for concurrency and ways of composing them together, which kind of makes it an interesting cage match environment for what concurrency primitives are useful. Actors would be really easy in Haskell, and they basically go unused. I suspect this means something.

parent jerf 9 years ago

Discussion

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton