[nberkman]

Interesting - this is the exact problem José Valim cited when creating Elixir: he was working on Rails multi-core performance in 2010 and found that "writing multi-core software, which is software that runs on all cores with Ruby, was not really straightforward."[1] Ruby's GIL meant only one thread executes at a time.

Fleury's arriving at similar conclusions from the C/systems side: make multi-core the default, not an opt-in. Though his approach still requires explicit coordination (LaneIdx(), barriers, range distribution) vs BEAM where the scheduler automatically distributes processes across cores.

Different tradeoffs for different domains, but both are reacting to the same backwards reality where we program single-core-first on multi-core hardware.

[1] https://www.welcometothejungle.com/en/articles/btc-elixir-jo...

[marvhus]

> Though his approach still requires explicit coordination (LaneIdx(), barriers, range distribution) vs BEAM where the scheduler automatically distributes processes across cores.

I don't see how a separate and abstract scheduler handing out tasks is any faster/better.

Being explicit isn't always a bad thing. It lets you better understand and control what is going on, which is very useful. For example: in one of the examples Fleury gave in the aticle, he showed how you could take advantage of this explicitness to avoid having to wait on other threads just to get a new task to work on. (https://www.rfleury.com/i/172146732/dynamically-assigning-ma...)