4 ms·

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 introd

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.

epergo 6y ago
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.
pdimitar 6y ago
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.
- joelbluminator 6y ago
  > make scheduling preemptive like the Erlang's VM does Care to explain this one? Btw Actors are basically pushing everything to an event loop, right?
  - pdimitar 6y ago
    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.

epergo 6y ago

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.

pdimitar 6y ago

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.

joelbluminator 6y ago
> make scheduling preemptive like the Erlang's VM does Care to explain this one? Btw Actors are basically pushing everything to an event loop, right?
- pdimitar 6y ago
  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.