I subscribed to your channel, power to you to finish up this series :). I love Nim, I even wrote a book on it! https://xmonader.github.io/nimdays

Thanks! I plan to record many more videos. Had some unplanned construction going on in my house so my recording setup is unavailable for a bit. As soon as it's done in a few weeks, I'll put out more videos.

Your book looks great, will check it out.

Just so you know, the call for speakers for the 2024 Carolina Code Conference (polyglot) will open January 1.

A Nim talk would be a great fit for the event.

> 2024 Carolina Code Conference (polyglot)

Thanks for mentioning this! I work remote in SC and its nice to hear about a nearby convention.

Nim should be more popular, but it seemed to take some time to get started properly. It's now far more ready for serious use. Python also took some time before it took off, so there's hope.

I have a handful of Nimble packages. Lovely language, though I haven't done much with it recently. I wish it were easier to sell people on style agnostic syntax.

I was using Nim for some of last years Advent of Code problems. I was mostly liking the syntax. Was a bit bother by the standard library have a snake case and camel case reference for each function (if I'm remember that correctly).

At the time nimble also required me to have NPM to install the the Nim package manager, Nimble. This was not ideal, but looking at [the nimble project install docs](https://github.com/nim-lang/nimble#installation) it seems like it is now package with the language.

Might try dusting it off for some AoC puzzles this year :)

I believe the whole language is "style insensitive" for variable names. So it's not just a feature of the stdlib.

Are you serious?

Yes. It’s so you can maintain a consistent style in your code base even if your dependencies use different styles. Nim has excellent C/C++ interop and it’s relatively common to interact with C or C++ symbols directly, and being able to do this without needing to adopt the dependency’s style or wrap everything is nice.

In python, for historical reasons the logging module uses camelCase while most other modules use snake_case, so it isn’t really possible to use the logging module and maintain a consistent style. This is a non-issue in Nim.

The downsides of this approach are unfortunately that it makes wrapping certain low-level libraries an absolute pain in the ass (especially anything to do with keyboards). But overall it's a non-issue, tooling recognizes both styles and you don't notice it.

Nim 2.0 changed the default to treating style mismatches as warnings.

E.g. it's something to check but not an error. You can easily set a config to make them an error or ignore them.

Cool, that definitely sounds like a welcome improvement.

There's also `atlas` that was released with Nim 2.0.

http://nim-lang.github.io/Nim/atlas.html

More power to nim. It just needs better tooling, IDE support.

I hate nim for depriving me of the joy to use tabs instead of spaces. It's just... unreasonable.

Set tabs to 2 spaces in your editor.