| I take a neutral stance on this: the JVM isn't as amenable to the exact kind of concurrency that Erlang provides (green-threads with local GC backed by immutable data), but that isn't a fair assessment of concurrency. Erlang (et. al. green thread models) has a method of concurrency that works well for situations you're using Erlang for. It's not the most efficient or most technically advanced mechanism for handling concurrency. That being said- > Without virtual machine support, doing concurrency is really just faking it This is patently false, because it implies that:
- A VM is necessary for "real" concurrency
- (by deduction) Anything not utilizing an erlang-identical model is "faking it." > will result in significant bugs later on that are essentially impossible to debug I'm going to need to see an anecdote or citation for this. Personally-speaking, I have a much easier time (quickly) understanding the execution of event-loop-backed cooperative multitasking than high-level, arbitrarily-preempted threads. Also - I cannot see any reason why Quasar for the JVM would be any easier or harder to debug (from a theoretical, not tooling or practical standpoint) than Erlang actors. The nuances differentiating the two models aren't great enough to merit bugs that you might see in one place or the other. Unbound, CPU-heavy tasks will cause problems for both systems. |