1. 28
  1. 10

    I was initially confused thinking this was what had been announced previously. However, the distinction is that they’ve opened sourced an LLVM based ahead of time compiler for Ruby, in addition to the type checker released previously.

    1. 4

      Mypy has gone a slightly different route where it generates (sometimes pretty giant tbh) C files to get compiled into native extensions.

      Unlike ruby tho, CPythons native extension support means no need for monkey patching tho. It all basically works safely with no futzing about, using CPython APIs.

      1. 3

        That’s the same here. The only patch they mention is to change load order so if you ship both the rb and the so file to production (which I guess they’re doing so they can quickly turn it off if it breaks?) the so gets preference. In a normal scenario where you trust the compiler you would just ship the so and no patch would be needed.

      2. 2

        Continuing to prove to the haters that “interpreted language” does not exist just because no one happens to have written an AOT yet

        1. 5

          Cython was there earlier with the same idea. But this doesn’t really change the whole model the runtime relies on. The languages which started with feature-rich interpreters will still include things that initially-compiled languages don’t usually carry. For example sorbet modules still have to resolve object attributes from names because that’s the assumption of the language.

          Yeah, the “interpreted language” name is not that great, and maybe we could use something more precise… But the origins of the language do influence the limitations.

          Or differently phrased: for most languages that started with interpreters, the best thing you can do for compilation without sacrificing any language feature is to effectively inline the bytecode interpreter in the code. (With some small optimisation) If you go further, you’ll start to lose features - and at that point is it even the same language anymore?