3 ms·

In all honesty, I'd recommend the use of Erlang alongside a framework like Chicago Boss, N2O or Nitrogen over Play if you want the actor model concurrency, defa

In all honesty, I'd recommend the use of Erlang alongside a framework like Chicago Boss, N2O or Nitrogen over Play if you want the actor model concurrency, default asynchronicity and WebSocket support. It simply supports these ideas in a way that Scala cannot compete with, alongside its concurrent error handling, the OTP framework, location transparent distributed nodes out of the box, binary pattern matching and so forth. Issues of typing aside (success typing is still impressive), it is a much cleaner and more FP-focused language than Scala's chimera paradigm.

bad_user 12y ago
The actor model for concurrency is rather poor depending on use-case. I prefer to mix and match approaches. I mean, modeling concurrent state machines, with bi-directional asynchronous communication that makes you easily lose sight of how data moves in your architecture, what could possibly go wrong? And yes, it's a pretty good model for concurrency, however I consider it to be a compromise on the way to finding better approaches. And in the meantime, it just feels wrong to use a language that forces this mentality on you, unless you have specific use-cases for which this model fits perfectly that is. And also, on the FP side - many people say that Scala is less FP than other languages, like Erlang. That's a rather odd assertion, because my experience has been the opposite. But that's for another discussion.