1. 18
    1. 25
      • You can safely skip to 5:42; before that is just a preamble about math and music notation as a metaphor for backward compatibility.
      • So, Nim 2 doesn’t have any big breaking changes, and there are some workarounds/polyfills to be able to use new features in a way that can still compile in 1.X.
      • You can specify default values for object (struct) fields, yay
      • An optional “strict defs” compiler mode emits warnings if a variable is possibly used before being given a value, if you don’t want to rely on default values.
      • “out” annotation on a function parameter tells the compiler the variable passed to that arg will be initialized when the fn returns.
      • Major improvements to the effects system that make it a lot more useful. I’m excited about this! A function that takes callbacks can specify it has all the effects of its callbacks. And a “forbids” annotation prevents a function from having a certain affect, either through regular calls or callbacks. This will be great for limiting the propagation of things like unsafe behavior or I/O through a codebase.
      • Unicode characters can be used as custom infix operators — apparently math people strongly requested this, which makes sense, but I’m wondering now what characters can be used? Can I use emoji as operators now? And how long until we have an APL syntax implemented as Nim macros?
      • Some minor enum quality-of-life improvements
      • “Tasks”, a new infrastructure library that just wraps an expression for lazy evaluation, for use with threads. This just sounds like a lambda with no args or return value to me; not sure what’s new about it, but I haven’t read any real docs yet.
      • And last but not least, the newish memory manager ORC “Optimized Ref Counting” introduced in 1.4 is finally baked enough to become the default. It’s gotten many more optimizations in 2.0. This is the kind of state-of-the art GC that is showing up in newer languages like Swift, where memory management is automatic, heap objects are ref-counted but most (“80%”) retain/release calls are optimized out at compile time. ORC also has a fast cycle collector so you don’t have to worry about leaks as in Swift.
      • ORC also allows a single heap to be shared between threads, no need to copy objects passed across thread boundaries as in e.g. Erlang.
      • To be released by the end of this year “or we’ll die trying” :)

      I’m excited, though I haven’t actually used Nim in more than a year. It’s still a language-crush. Yeah, I’m the guy in the meme who’s holding hands with C++ but looking over his shoulder at Nim.

      Actually I’m holding hands with Go and TypeScript too (hey, it’s complicated!) Go is more of a work obligation: its error handling is as wretched as ever (half the LOC I produce are “if err != nil {return nil, err}”) and the hyped new generics feature is less useful than I’d hoped. TypeScript is definitely a crush: very fun to use, very productive, but I don’t think I can settle down with it long term because a lot of what I write is low level and needs to run fast and compile native.

      By this analogy I guess Rust is the one I had a crush on at first, until the night it blew up and went psycho on me, screaming about all the stuff I’d borrowed without proving I’d give it back, and I had to call the cops. 😬

      To me, Nim feels like a nice compromise between Rust and TypeScript. Less strict/rigid than the former, more efficient than the latter.

      1. 5

        thanks for writing it up!

      2. 4

        Unicode characters can be used as custom infix operators — apparently math people strongly requested this, which makes sense, but I’m wondering now what characters can be used? Can I use emoji as operators now?

        There is a fixed list of operators.

        “Tasks”, a new infrastructure library that just wraps an expression for lazy evaluation, for use with threads. This just sounds like a lambda with no args or return value to me; not sure what’s new about it

        I asked Araq during the talk and he said there are some subtle differences with threading, but maybe it could be made a special variant of a proc().

      3. 3

        To me, Nim feels like a nice compromise between Rust and TypeScript. Less strict/rigid than the former, more efficient than the latter.

        I feel the same, and it’s what’s led to me using Nim pretty extensively for the past 12-ish months, and I love it. I’ve got some problems with it that I run into occasionally, but I feel that way about every language :)

        Looking forward to 2.0!

      4. 2

        Is Nim still treating Javascript as a first class citizen for its output (this is very nice in my view)? Are there significant changes/enhancements in this area (I am not looking for anything specific, but you had an informative post above, thank you for that, and I just wanted to pick your knowledge a bit more).

        1. 3
          1. AFAIK, yes.
          2. I don’t know of any, but I’ve been out of touch with Nim for a while.
        2. 3

          Yes. Unfortunately, the JavaScript it produces is quite bloated (several kilobytes for a “hello world” script) and Araq doesn’t want to do anything about it.

          1. 1

            thank you, do you know reasoning behind it. Eg, should the JS minimization/optimization pipeline take care of the bloat you mention, or there are more complex issues there?

            1. 2

              His reasoning is that computers with a slow/limited internet connection don’t exist or don’t matter, pretty much.