I posted this before because I really enjoyed this talk. I worked for John O’hara about 20 years ago - he was the one who started AMQP (RabbitMQ).
This talk made me have a lot of thoughts about the kinds of software systems we could build on modern CPUs.
When I think about threaded actor model, CPU affinity and cache aligned architectures, I also think about how could we do this with Elm ? How could we take advantage of this hardware without compromise, yet build in an aesthetically brilliant language (Elm) and use domain modelling to build software that “makes illegal states impossible” at the same time. That is the goal that I am aiming for, although it is still a long way off to achieve it.
So now you know why I posted about Elm + threads: If Elm had threads..?
And there is an experimental API and simulation of it here: GitHub - rupertlssmith/elm-with-threads: What would Elm with threads be like? · GitHub
eco runtime is currently single threaded only. Your program thread even runs the garbage collection! I am already thinking about how to introduce threads into the implementation - the API side seems fairly clear - but on the implementation side, when to have heaps that are shared between threads or not, when considering the question of how to have the highest possible event throughput between threads.
Perhaps it is better to tackle reference counting first, and eliminate much of the GC work.