To me, 3.0 is not super interesting per se, but it's a great ground to make future releases compelling, congrats to everyone involved, and thank you for your work.
The thing is the language is complete (imo).
I don't want them to reinvent the wheel or break backwards compatibility like python 3 did. And please don't introduce explicit types into Ruby for god's sake.
So what's left to work on? I guess the things they're doing now: better performance, better tooling etc.
Double down on actors and async I/O, make scheduling preemptive like the Erlang's VM does, and make message passing the preferred way to do multicore-CPU-enabled work.
Nobody is requesting new language features for ages now. They are very rarely needed. The runtime is what needs a lot of work.
Yes they do but that won't help you if one bad actor (literally and figuratively) takes a long time to execute a single function call. Erlang's VM has machinery to multiplex actors on separate CPU cores and keeps around several different kinds of thread pools -- native (as in Erlang bytecode) actors, dirty I/O threads (where potentially long-lived I/O will live) and dirty CPU threads (where CPU intensive tasks go) -- and can move actors between them (although let's be honest, nobody can make that work reliably and Erlang makes mistakes there as well).
Basically, as they call it, several different schedulers, each with its own pre-warmed thread pool.
An event loop is a step in the right direction. I am just worried that Ruby 3.0 might turn out how OCaml Multicore is turning out -- an endless saga.
Completely agree about the tooling bit, after working during some time with Golang (just a bit during these past years) one of the things that I most like about that language is the set of official tools that it has, from formatting your code to check for security issues or unreachable code.
It helps the developer to be more confident about its code.
