How so? AFAIK BEAM is pretty much agnostic between work-stealing and work-sharding* architectures.
* I prefer the term "work-sharding" over "thread-per-core", because work-stealing architectures usually also use one thread per core, so it tends to confuse people.
The BEAM schedulers are work stealing, and there's no way to bind a process to a scheduler (or at least, there's no publically documented way in upstream OTP).
You can adjust some settings for how schedulers work with respect to balancing load, but afaik, work stealing cannot be disabled... when a scheduler has no runnable processes, it will look at the runqueue of another scheduler and steal a runnable process if any are availabke (in priority order).
It does default to one 'cpu scheduler' per cpu thread, plus some i/o schedulers and maybe some dirty schedulers.
Come and have a chat at elixirforum.com. Plenty of folks write serious stuff entirely/predominantly in Erlang/Elixir & BEAM and will be happy to answer your questions.
"Skills work through progressive disclosure—Claude determines which Skills are relevant and loads the information it needs to complete that task, helping to prevent context window overload."
So yeah, I guess you're right. Instead of one humongous AGENTS.md, just packaging small relevant pieces together with simple tools.
yeah you need to read through its templates and "source code" to understand what it does - which is not necessarily a bad thing for this type of project.
I like the part that uses custom slash commands as way to wrap your input into some well-structured prompt template for given type of task. I like the part that also injects relevant pieces of "broken down AGENTS.md" as I see it.
I don't like the part that tries to leave no knot untied, which creates that sledgehammer for cracking a nut, as mentioned in the article. But I am sure it's easy to add another custom slash command like "/experiment" or "/stub" that would bring those context management benefits without the bloat, in situations when you don't know yet what and how you want to build something.
And then maybe "/wrap-up" to tie all the untied knots once you're sufficiently happy. Kinda like surgeon stepping aside after the core part of the operation.
It was actually fantastic even for creating websites. To think that 20 years later we still don't have tools to make similar stuff with similar ease is mindblowing.
We advise developers to include examples in their documentation, often under their own ## Examples heading. To ensure examples do not get out of date, Elixir's test framework (ExUnit) provides a feature called doctests that allows developers to test the examples in their documentation.
Doctests work by parsing out code samples starting with iex> from the documentation. You can read more about them at ExUnit.DocTest.
I don't think they can keep it. What they have has already been replicated by the big guys, with just maybe a few months delay. It seems like they're usually going in the right direction, even ahead of others, but it's usually not any massive breakthrough, they're just being good at executing quickly the natural next steps.
