[yeck]

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 :)

[mb7733]

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

[gemstones]

Are you serious?

[dsrw]

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.

[j-james]

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.

[elcritch]

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.

[yeck]

Cool, that definitely sounds like a welcome improvement.

[cmdlineluser]

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

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