Learning Programming with Nim (opens in new tab)

I have spent time learning, messing around with, and evaluating each of the languages that you have listed. In the end, I decided to go with Rust for my particular application, which is a large (100k SLOC) GIS application. Rust and Zig are probably the fastest of the listed languages, although Nim and Crystal are not far behind. I found Nim to be the easiest to program in, despite my lack of Python background. The friction factor seems the lowest. Crystal is quite a nice language, but I have reservations about its future, which have been shared by its originator (the compiler may not scale well), and it does not have Windows support or support for multi-threading. If these obstacles are overcome, it could be really interesting. Nim is really great, but they have to hit v1.0 by the end of year. I'm not sure if the devs realize how important this is to the user community. Zig is quite interesting, and highly performant, but it is probably at the earliest stage of the listed languages. Rust is certainly the furthest along in development, has a larger user community and learning resources. It's not the easiest language to learn or use. I agree with your assessment of the language but will say that things get much easier once you've spent some time with Rust.

The other languages that you didn't mention but are worth evaluating are D and Go. Again, they have advantages and disadvantages that may make them either more or less suited to your application.

I would say that Nim ticks all of the main things you are interested in. To give you a better idea let me go into a bit more detail about your interests:

> I want to write once and run on Windows / Linux / Mac. (I'm not writing a GUI.)

Portability is Nim's great strength. You can even target some really obscure platforms, as long as they have a C compiler (which they likely will).

> Concurrency and async capabilities

Concurrency in Nim is offered via async await with first-class support for Windows, Linux and macOS (IOCP, epoll and kqueue). It's implemented 100% using Nim's macros, so you can easily dive into its implementation and modify it to suit your use case without having to mess with the compiler source code. It's all implemented in the standard library.

Nim's async has also been used in production for quite some time now. One example is the Nim Forum: https://forum.nim-lang.org.

> Safety guarantees (both types and threads)

Parallelism in Nim is a little different than in other languages. Each thread has its own GC and memory sharing between threads is limited. This ensures safety and performance (no stop-the-world GC).

> Speed

Out of all the language's you've mentioned I would say that they are all pretty similar in terms of speed.

Hope this helps!

You may want to consider Pony: https://www.ponylang.org/

Pony has compile time guarantees on not having data races, dead locks, runtime exceptions. It accomplishes this in a different way than Rust. For concurrency/async, Pony is Actor based, which I find to be a joy for modeling concurrent applications.

Here's a high level: https://www.ponylang.org/discover/#what-is-pony

If you don't mind GC I would go for Nim (although I don't have much experience with Rust or Crystal).

I've always enjoyed programming in Nim when I've had the chance. It doesn't fit all kinds of projects, but it sounds like it'll fit yours.

Zig is too young to build anything significant with it. But to me, it's the most promising language for embedded and low-level development, and where you need good control of memory management. I've played around with it a lot recently and looking forward to use it more in the future.

You might also consider OCaml. If the syntax offends you, ReasonML might not be a bad option.

I would add D to the list, and eventually C# although its AOT compilers depend a bit in what toolchain you end up using.

> The languages I've been considering are Rust, Nim, Crystal, and Zig.

Sorry to be unfair but: is being _new_ the prime quality of a programming language?

I would also consider D

Have you looked into Go?

I see Nim as inhabiting an interesting space between Lisp and Python/Ruby/Perl.

I wouldn't say Nim is "radical", but it is interesting in that it combines ideas in a way that I've not seen in other languages. Whether or not it really takes off, it's a good thing that it's around - if nothing else, it's a slightly easier way for devs who work primarily in higher-level languages like Python and Ruby to encounter concepts they might not otherwise encounter, like macros and a complex type system.

This tutorial obviously only scratches the surface of what is possible in Nim. If you want to dig deeper I recommend reading through the learnxinyminutes entry, along with maybe https://xmonader.github.io/nimdays to see some examples. Then of course the official tutorials. Or if you just want to dig into the crazy stuff to see what is possible https://hookrace.net/blog/introduction-to-metaprogramming-in...

Nim is definitively niche but it's not really new, Wikipedia tells me that it's 10 years old (older than Rust [2010] or Go [2009] for instance). It just never got enough traction to really find its place in the ecosystem.

Nim isn't a new language, it's been around a while.

> Case- and underscore insensitivity

This is a great feature when interfacing directly with C libraries. You can declare the names as they are in the original library, which is best for debugging and reference. They can be a variety of styles, but in your code you can refer to them all with camelCase so you have a consistent style in your own code.

I've never had any problem with it. It just works, and if you don't want to use it, it's not going to be an issue.

> this is a very well written tutorial. Might be a nice format to use in other basic language tutorials.

Author of the tutorial here. Thank you very much for your kind words!

> Significant whitespace and case- and underscore insensitivity. That's pushing too many of my buttons for one language.

Coming from Python, I had no problem with the significant whitespace. I like it more than curly braces everywhere.

Case- and underscore- insensitivity were something I initially really didn't like. What were they thinking? Are they out of their minds?

After using Nim for a year, I must say I didn't experience any problem with it so far. All the code I have written, all the code from others I have read uses camelCase (which is a recommended, but not enforced, case). So basically, even though people have an option to use snake_case (or any other), the large majority of users use only the one style.

For example, what do you think of Go? It's case-sensitive and whitespace-insensitive, but almost everyone formats their code with gofmt, which next to eliminates "creativity" with whitespace, letter case and braces (but makes the code uniform and readable across authors).

it isn't entirely case insensitive, just to clarify.

If I may be so bold as to comment on form rather than function, I wanted to say I am not particularly fond of the typography / design choices for the tutorial.

I know this is dangerously close to bikeshedding territory, but if I may, I wanted to point you to a similar resource that I recall being particularly pleasing to read way back when I was getting started in Python / Django:

https://web.archive.org/web/20080730140551/http://www.django...

That content has been retired from djangobook.com, and the website's design has followed suit, hence the archive.org link. I suggest also perusing the table of contents and making note of small design hints such as the use of color, whitespace, "Note" callouts, etc.

At the very least, I hope you'll find this inspirational if you decide to take a moment to rethink typography, typesetting and the overall design of the website and PDF.

I'm going to start this comment by saying I think this is a really good overview of Nim, and I think it's a good tutorial for experienced programmers who want a quick overview of the language. This tutorial is good for programmers who know how to program in other languages, and want to do so in Nim.

But while I think the content is good, I think your framing is way off. You state explicitly up front that this document is not for experienced programmers, but for novice users and people unfamiliar with programming. You go so far as to assume they're so novice that they don't know what "printing" means in terms of text to a screen. I'm going to kindly suggest that this document won't be very helpful at all for those users. To illustrate why I think so, I'm going to walk you though reading this document from a true novice perspective:

I'm reading the tutorial. I follow the installation instructions, and all of a sudden I'm installing over 500 MB worth of stuff to my machine? Many novice users may be coming from Windows, and some warning about this upfront would go over well.

As a user who you assume doesn't understand even the basics of printing to the screen, you've asked me to download and install 500 MB worth of stuff just to run the compiler, and then you suggest I may need three additional tools (well do I or don't I?as your reader, I'm here for your opinion. I don't know the merits of any of these tools). It's more helpful to be authoritative in situations like this. Leaving too many options open for a novice user leads to confusion.

But I persist, and I've downloaded your language tooling, MinGW, VSCode, assorted plugins and other things, and I don't really know what they're for. But after all of that, the payoff is to print a word to the screen. I would be a very determined reader if I continued at this point.

But the remainder of the tutorial is supposed to take us from readers who don't know programming at all, to readers who can write programs. And the way you've chosen to do so is to introduce notions of types of data, and then build on that to the point where you are doing operations on data. That is a tried and tested pedagogical tactic for presenting new syntax to experienced programmers, but the novice is left fumbling and confused about what those data types are for and how that relates to the problems they'd like to solve with this language.

You don't let the users write an honest to god program that has input and output until the very end of the tutorial.

I'm sorry if I seem overly critical, but I think this tutorial could be much much improved if you just admit what it is (a tutorial exposing Nim syntax to experienced programmers), and reframe it as such.

You should check out the newly redesigned NimForum[1][2]. It is written 100% in Nim using Jester and Karax (a Nim framework similar to React). Karax itself has a number of examples in its repo[3], we're also always happy to help you out if you want to pop into IRC or post questions on the forum :)

P.S. Thank you for the kind words about Nim in Action!

1 - https://forum.nim-lang.org/

2 - https://github.com/nim-lang/nimforum

3 - https://github.com/pragmagic/karax/tree/master/examples

There is already a nim react package. There is also the web framework karax you could use instead. Zero docs for that though

Nim has type inference as well, but the type still has to be known before we can use a value.

From the tutorial:

> Nim also has type inference ability — the compiler can automatically detect the type of a name assignment from its value, without explicitly stating the type.

> That is the clearest, most succinct explanation of variables, types and mutability I’ve ever read.

Thank you very much! It means a lot to see this kind of feedback.

> It’s difficult to break ‘obvious’ things down to those without background while staying concise.

After writing this tutorial, I can only nod and agree with this statement - it took me much more time than I originally thought it would.

Yeah Narimiran did a good job of breaking it down. I prompted him to add details here and there, but he was quick to rein me in when I wanted to dig too deep.

> I'll take the chance of suggesting also Dominik's book (1) both because it's good

Thank you :)

> I can politely ask the publisher next time please do use bigger or darker fonts for code

I think it's unlikely the publisher will see your message here. You might have better luck Tweeting at them or emailing them.

There have been insightful comparisons in both communities:

Nim: https://forum.nim-lang.org/t/1779

D: https://forum.dlang.org/thread/mailman.1427.1428691340.3111....

And the following is probably one of the most extensive comparisons of the two languages: https://github.com/timotheecour/D_vs_nim/