Another thing: I am curious how do you resonate with “Erlang + BEAM + OTP vs Java + JVM + Akka” stacks? I have almost 0 knowledge on it, read some basic articles on the comparison, but I’d really like to see what are your thoughts on that in this channel. Any theoretical or practical pennies are welcome 🙂

the BEAM has green threads, preemptive multitasking for processes, and per process heaps/GC. the JVM doesn't have native green threads, actors build on top are cooperative and has a global heap. I can expand if you want 🙂

@Mariano Guerra Ahh that is really useful! Especially the fact orleans is something similar! Thanks a lot! Could you please expand on these? :) • “Actors build on top are *cooperative*” • “messages are copied when sent” - how is that not possible on jvm/akka? It is, right? Or with some downside opposed to the erlang version? • “most of BEAM features have some JVM equivalents, but the BEAM is built from the ground up to solve those problems” - Is it possible that on the long run virtually all features will be implemented on JVM and with the perf + ecosystem difference BEAM will slowly fade away? If you would not bet on that, why? • “I like orleans more” - that is interesting! Why is that?

In Erlang/BEAM the runtime partitions the memory into isolated heaps. Cross heap references are not possible. All code evaluation is done by the runtime so all objects created only refer to the local heap. If you send something over to another heap, it is copied. This is similar to how Unix processes have isolated heaps. The JVM is one big heap and any object cam refer to any other object anywhere. The runtime itself doesn't prevent any references. Now if you implement a framework on top that creates partitioned heaps and allows copying - you can only get so far. There will always be holes and once you use any shared library outside your framework, all bets are off. This kind of isolation is very hard to retrofit. Python has the same limitation (as Java). A similar thing happens with lightweight threads. The Erlang runtime decides which heap/process (each heap is associated with a process) gets to run for how many steps. Then it can run another process for some steps. The multiplexing is preemptive so no tight loop can starve other processes. With user threads in Java, the code is supposed to call

yield

or something like that every so often and only then control goes back to the main loop which will schedule another thread. You can have starvation and latency spikes. Again this is hard to retrofit. The only preemptive scheduling available in JVM uses the (heavy) system threads. FWIW, I think the Erlang isolated heap lightweight process model is great. Go copied the lightweight process (with preemptive scheduling) but it still uses a single heap.

@Pezo - Zoltan Peto Shalab explained preemptive/cooperative above 🙂

@shalabh Awesome! Thanks! @Mariano Guerra What about your orleans, why do you like it the most? :)

the concept of virtual actors, actors that "always" exist and the lifetime is handled transparently by the runtime, this means you can send a message to an actor and don't care if it doesn't exist yet, just crashed, was suspended or is being migrated to another node, the runtime will take care of finding it and delivering the message. The same with runtime support for actor state persistence.