[dsrw]

I tried Nim on a lark 3 years ago. I was writing a learn-to-code tool in Godot and was getting frustrated with some of the limitations of GDScript, so I decided to build it again in Nim. It was very much a "I don't want to do what I'm supposed to be doing right now, so instead I'll play with something shiny" moment, and I fully expected to hit a wall within a few hours and get back to doing things the normal way. But the wall didn't come, and after a few days with Nim I tossed the GDScript version.

In no particular order, things I like about Nim:

- It has most of the benefits of a scripting language, without most of the tradeoffs. Hello World is a one-liner, there isn't much syntactic noise, and it's very easy to write short, simple, useful programs that look like pseudocode, live in a single file without any dependencies, and can be kicked off with a shebang line. However, unlike scripting languages, it scales very well to large projects.

- Progressive disclosure. You can use Nim effectively while knowing very few of its features, but there's a lot of functionality available when you're ready.

- The "if it compiles, it works" factor is quite high. Not as high as Rust or Haskell, but higher than Java or Go, in my experience.

- The "it compiles on the first try" factor is also quite high. Higher than any language I've tried. "I wonder if this will work..." code usually does, the advanced features of the language mostly stay out of the way until you need them, and I rarely find myself working just to make the compiler happy. Just as an example, unless you add specific constraints, generics are "duck typed". If I pass a type to a generic proc the compiler will verify that it has the properties and functions the proc needs, but I don't have to define a specific interface up front.

- Similar to the above, the productivity vs safety balance seems right, at least for me. Code is fairly safe by default, but it's easy to work around the compiler if you need to do something it doesn't want you to do. It's also pretty easy to enforce additional safety when you need it, like ensuring a function can't throw exceptions or have side-effects.

- It's very good at building abstractions and eliminating boilerplate. Nim templates and generics are easy to use and quite powerful, and macros are there if you need something more advanced. Many features that need explicit compiler support in other languages, like async/await and string interpolation, are implemented in the Nim sdlib with macros, not the compiler.

- Nim produces standalone binaries that are both small and fast.

- The compiler is faster than most.

- The compiler can be imported as a library, making it pretty easy to write tools that understand Nim code.

- Nim programs are usually compiled, but there's also an interpreter. The compiler uses this for macro evaluation and for running build scripts, and it's easy to embed if you want your program to be scriptable.

- Nim can run on pretty much anything.

- Nim can be used to build almost anything. You can use it for systems programming, webdev (frontend and backend), games, ML, scripting, scientific computing, and basically anything else. There are definitely some domains where library support is lacking currently, but the language itself is suitable for any type of program.

- It's very flexible. Most Nim code is imperative, but it's easy to write functional, declarative, or OO style code if that's your thing.

If you prefer languages like Go that favor an abstraction-free style, where everyone's code looks more or less the same, you probably won't like Nim. However, if you want something more expressive like Ruby or Lisp, but don't want to sacrifice performance or safety, Nim is definitely worth a look.