1. 23
  1.  

  2. 6

    This is Yorick Peterse’s language Inko, and he left the corporate world this past year (I think it was this past year, maybe even longer ago now) to focus on Inko full time.

    1. 4

      This language looks great! The only thing I’m disappointed / confused by is that it’s interpreted. That seems odd considering the focus on performance — a bytecode interpreter must have much higher overhead than a garbage collector. Is this just a temporary condition and it’ll eventually switch over to native compilation?

      1. 8

        a bytecode interpreter must have much higher overhead than a garbage collector

        I guess you meant “higher overhead than a compiled language” or something along those lines. The answer is yes: a bytecode interpreter has more overhead compared to a compiled language. The choice is mostly historical: Inko started out as a dynamically typed language, then moved to a gradually typed language, then to a statically typed language. I am looking into compiling to machine code (see this issue for more details), but it will probably take a while to get there :)

        1. 3

          No, I did mean that the performance hit of running a bytecode interpreter is probably worse than the performance hit of using a garbage collector.

          IIRC, even good bytecode interpreters are in the ballpark of 10x slower than native code. Not speaking as a runtime/interpreter expert, but it’s an area I take an interest in, and in particular I’m recalling recent shootouts of various WASM interpreters vs C code.

          1. 10

            No, I did mean that the performance hit of running a bytecode interpreter is probably worse than the performance hit of using a garbage collector.

            While an interpreter without a JIT isn’t going to outperform machine code, its performance behaviour is at least constant. A GC on the other hand is wildly unpredictable, and the performance impact can vary from very little to a lot.

            This release is the first step towards more predictable and better performance by getting rid of the GC. Also getting rid of the VM likely would have delayed the release by at least another six months. Given that raw performance isn’t a huge priority at this stage (e.g. a useful standard library and package manager is much more important), I decided to set this aside for the moment. This also gives me some more time to look into what approach we’ll take, without the pressure of a release that’s still waiting to be pushed out.

            1. 4

              That’s eminently reasonable. I look forward to future releases!

      2. 3

        This sounds great. Is it ready for “real” usage?

        Reading this doc, I don’t think there’s a big idea here, rather “similar safety goals to rust but embracing a different set of affordances and concurrency as a first class design concern”.

        1. 5

          You can write “real” programs in Inko, but it will be a bit of a challenge due to the small standard library and lack of a package manager. There’s a reason why it’s still version 0.10.0 :)