(I posted this earlier to the OS VM group (vm-dev@lists.squeakfoundation.org), but the message appeared as an attachment. I'm not sure that was the right place; so I'm reposting here.) Hi all. I was reading about the RoarVM, recently. The project seems to be at a standstill. Why, as in the RoarVM, would someone try to build a Smalltalk VM supporting concurrency, and not also resolve to use a strict actor model in which each process has its own, usually small heap that is very quickly and simply GCed? If I understand correctly, RoarVM still had one big heap for all processes. With one heap per process, many times no GC happens at all: the process finishes and the heap is discarded. This finer-grained memory-management dynamic gets us closer to deterministic latencies, which are needed in simulations (and almost anything graphical you want to render smoothly). The idea with the actor model (and the OTP-style work-stealing that accompanies it) is not only to use very continuously all cores in all CPUs in all machine-nodes on the network, all of the time (until the program exits or goes idle), but also to make using the usual synchronization devices (semaphores, mutexes, monitors, and the like) unnecessary. This is where all the complexity is and where the time and effort go when coding and debugging concurrent apps. No one wants to use these devices if he needn't. The actor model is an elegant way to solve the concurrent-programming problem, which mostly reduces to advancing program state with only asynchronous messaging, while causing no blocking and no idle cores if there is still work left to do. The actor model works if you are willing to build a proper state-machine for your app (I have some ideas for a GUI to help in this respect) and the asynchronous messaging is fast. It is very fast in Pony (https://www.ponylang.io/). (Smalltalk images linked by WS connections won't be fast enough.) I'm learning to use Pony these days. It's a good tool, and it's improving at a good pace with an enthusiastic community. It's statically compiled; so it's not speeding development/experimentation as much as it is the resulting program. However, Pony vastly reduces the amount of concurrency-related debugging you would otherwise do if you did not, after a successful compile, have a provably non-deadlocking/non-data racing program. This is the new thing that Pony gives you, and it's great. But I want a dynamic development environment and very efficient Erlang/OTP/Pony-style concurrency. How do we get that? Why wasn't this the path chosen by the RoarVM developers? What is happening in OpenSmalltalk VM regarding such concurrency? I'm considering using Pony somehow in a 5-pane browser (but that's some work), dumping compiler errors to the Transcript. I'm not fond of editing text files (scrolling/searching) even when the process is very graceful. That's too 20th-century. VS Code is a very nice tool with great extensions, but it does not replace what happens in a Smalltalk browser. Please share your thoughts on what is happening or what could be done to create Erlang/OTP/Pony-style concurrency in Smalltalk. Cheers, Shaping