1. 22

  2. 18

    With Ruby 3, Matz hopes to introduce better concurrency primates for Ruby!

    That is not entirely surprising, because Ruby 1 & 2 encouraged a lot monkey patching.

    1. 12

      “I regret adding Threads.” ―Matz

      I had a largish body of threaded ruby code….

      • It was always slightly flaky
      • It didn’t scale up.

      I ripped them all out and replaced them by multi-processes. Rock solid and scales way up to 40 core monsters.

      We had another chunk which somebody else maintained that remained multi-threaded…. it got flakier and flakier until we threw the whole damn thing away.

      Fibers by Samuel “ioquatix” Williams.

      I had the pleasure to attend a meetup where this guy presented his stuff.

      Smart guy with some really Good Ideas. I’m looking forward to using them.

      1. 2

        I agree on multi-process. Both Matz and Koichi have said in the past said that this is the way to go for parallelism. IMO it’s the way to go for non-parallel code, too (because you can have multiple garbage collectors in the same process, each GC managing fewer objects, which means shorter pauses when the GC runs).

        Threadlets sound a lot like the green threads that we had on Ruby 1.6. I really liked green threads – the lack of a context switch meant that you could write threaded-style code but get the latency benefits of event-driven code. In 2002, we routed all our trading traffic through a little 50 LOC Ruby script using green threads, to work around a bug in our C++ code that would have taken days to fix. I had the Ruby script written in about 30 minutes, and we ran with it in production for months, before a proper fix could be deployed. It would never fly in today’s financial market (too slow), but back then it was a testament to how powerful this little language was.

      2. 1

        Wow those rbi “header files” feel like a big pain to work with. Obviously C/C++ folks manage to do it fine but it still seems like a strange option for Ruby. Having to maintain two versions of a class definition in two seperate files feels a lot less DRY than just having the types inline like Sorbet. I’m surprised Matz prefers this option.

        1. 3

          Honestly, it’s not as bad as C headers. OCaml has this - even down to the naming scheme. Multiple files are the downside but you don’t need an interface file if you don’t care for one. And if you write the interface first, you can largely forget about it (er, until you discover you messed up with the design).

          You can write the interface, then other code that uses the interface, then the implementation, if you want. You get private fields for free and the DRY problem becomes a blessing if you want multiple implementations. C headers do all this, sure, but it’s much easier when the tools do the boring stuff. You only have to remember to keep the files in the same folder.

          1. 3

            If I’m writing type annotations by hand, then I agree that inline is more convenient. Even in the C++ world, having separate interface and implementation is becoming the exception rather than the rule; since templates necessitate having the implementation available, both implementation and interface go into the header file.

            There is at least one good reason I can think of to keep annotations separate in the Ruby world: it allows the annotations to be generated by a tool without modifying the original source code. This could happen e.g. when you run your unit tests; as each method gets called, record the types of each argument and the return type, and emit a warning if a method is ever passed conflicting types.

            1. 1

              This is definitely the intention; I expect that writing an rbi file by hand will be uncommon.

            2. 2

              Being a C/C++ folk for a long time in my life, personally I always found header files to be purely an annoyance :/ I mean they have the important property of succinctly describing the public API, and also I understand how they came to be, but it always felt to me like nowadays they should be automated somehow. To me, the Go approach of presenting the API via Godoc is exactly how it should work.

              1. 2

                I think separate files are a lot better when you’re using a library, because you can see just the interfaces you’re using rather than having to skip over all the code. In fact I wrote a tool for .NET back in the day that would make pseudo-header files for reference (admittedly even more necessary since .NET allows closed source libraries). Godoc has a similar function in Go — the table of contents is basically the same as an interface header file.