6 ms·

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 c

by yeck 3y ago

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

cmdlineluser 3y ago
There's also `atlas` that was released with Nim 2.0. http://nim-lang.github.io/Nim/atlas.html http://nim-lang.github.io/Nim/atlas.html
deleted 3y ago
[deleted]
mb7733 3y ago
I believe the whole language is "style insensitive" for variable names. So it's not just a feature of the stdlib.
- gemstones 3y ago
  Are you serious?
  - dsrw 3y ago
    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 3y ago
      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 3y ago
    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 3y ago
      Cool, that definitely sounds like a welcome improvement.

by yeck 3y ago

cmdlineluser 3y ago

There's also `atlas` that was released with Nim 2.0. http://nim-lang.github.io/Nim/atlas.html http://nim-lang.github.io/Nim/atlas.html

deleted 3y ago

[deleted]

mb7733 3y ago

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

gemstones 3y ago
Are you serious?
- dsrw 3y ago
  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 3y ago
    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 3y ago
  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 3y ago
    Cool, that definitely sounds like a welcome improvement.