I've started using Nim couple of months before last year's Advent of Code, after I've been reading about Nim both here and on Reddit.
As a Python user, I was immediately drawn to Nim's elegant syntax, which looked to me like "ok, just copy-paste my Python code, and declare some variables, and voila: 10-100x faster Python!", which is 80% true. The remaining 20% were "this works in Python, why doesn't work in Nim?" questions, which were promptly answered by the great Nim IRC community. I soon realized that those differences are what makes Nim great, and I began to really like the language.
I decided to solve AoC 2017 in both Python and Nim [0] so I could directly compare my solutions. This was a great experience for me, and I've learnt a lot.
In the past year I started using/liking Nim more and more (I have used Nim even at my work (numerical calculations, before done in Numpy)). This year I'm gonna solve AoC solely in Nim.
From my experience, your hunch is right.
If you have any Nim questions, let me know.
Basically, Nim ignores case (except for the first character) and underscores in identifier names, so the following is a valid Nim program and all those names refer to the same variable:
var myVar = 1
my_var = 2
mYVAR = 3
echo(myVAR)
More on this: https://nim-lang.org/docs/manual.html#lexical-analysis-ident...
I feel like this is mentioned (by the people who just glance over Nim) every time there is some discussion about Nim, and IMO it is blown way out of proportion.
In my cca year and half of using Nim, I not even once had a problem with the style insensitivity.
IMO, you (general you) shouldn't use `my_foo` and `myFoo` for different things, regardless if a language allows for it or not.
Not hard to make up any number of examples where spacing or capitalization matter for good reason. They matter to humans; its just silly to make them not matter to the compiler.
Now back to your concern of identifiers being read in different ways meaning different things. Once you know that this will be an issue you tend to think about it when naming your variables, and so it tends to not really be an issue. The thing is that once you get used to it you know that `pidTarget` and `pIdTarget` is the same thing, so you either relax you expectations, or you don't construct your names with this ambiguity. And besides, a "pointer to a target id" and a "scalar process id" probably don't share the same type, so the compiler should be catching that anyways if you ever used it wrong.
grep -i solves the case issue, and grep/ripgrep probably _should_ have a feature to ignore _ ; in which case you will be able to use them - but until then, nimgrep will do that work.
I don’t know how atheistic style looks, but Nim is style agnostic - everyone can practice their religion and they all get along. C, Python, and the real world - not so much.
This one point is always worth considering when deciding on user-facing portions of technology.
Not to mention, in my opinion it's more aesthetically pleasing, but that's just me :)
(let ((|hello world| 3)
(|HELLO world| 4)
(|こんにちは (jp)| 5)
(|pi\|pe| 'piped)
(|newlines
work
too| 6))
(list |hello world| |HELLO world|
|こんにちは (jp)| |pi\|pe|
|newlines
work
too|))
; --> (3 4 5 PIPED 6)Search HN (box at bottom of page) for Perl6 and you will find many articles with references to kebab-case.
As mhd said, it's used in Lisp too.
But is not a deal breaker for me. If the language doesn't let me I can use `ii` or `i2` or whatever.
Please notice that the first letter in Nim is case-sensitive, so `I` != `i`, and you can continue use your conventions.
And before some new comment starts bashing that, I think this is a must so you can differentiate your types, written in PascalCase, from your variables, written in camelCase.
I did not know this about Nim and does also seem quite a big turn off and a bit of a WTF decision
I have never coded any Nim, just read about it though :)
I guess the intention is NOT to let you carelessly use Myvar, MyVar and myvar willy-nilly in your code, as I had first imagined
I assume the intention is to PREVENT you from deliberately defining those names as different vars, which would be confusing
So, on reflection, maybe it is not such a WTF
int main() {
int myVar = 1;
int my_var = 2;
int mYVAR = 3;
int myVAR = 4;
// ...
}
It saved me few bugs already.
I would love to find a language for game / engine development that's as performant as C++ and as easy to use as C# or Python, but this issue scares me. If I search for a variable using any of my existing plain text search tools, I expect to find the variable. It makes me think that this isn't a language that's meant to be used by large teams on large, long-lived codebases.
I think you are over-estimating how inconsistent Nim code typically is. I have been coding in Nim for a very long time and I personally just use case insensitive search (which I use for all languages anyway).
It's easy to tell from context what the identifier will be. If the code base is snake_case then I search for `foo_bar` if not then I search for `fooBar`. I cannot remember a single time this has failed me, and even if it does then the worst case is you'll need to search for the other alternative. There is really no trouble here and I feel like a lot of people, when they see this feature, worry too much because it's so different. Please please please reconsider, I know it's a strange feature and it doesn't feel worth it, but it really isn't a problem at all.
But mostly, it just seems like a really weird call to make for the language. There are real disadvantages to it -- I can't really rely on my search tools. So that... when you're using a library you can refer to its identifiers using a different capitalization convention if you want to--why is that important?
I don't know, it just seems like a really weird call to make, and if that's one of the first things I've learned about the language it makes me think there are probably plenty of other weird things like it.
But why? I personally haven't experienced this having worked in a big Nim project. I'm really curious why you think a bigger project could become burdened by this.
> There are real disadvantages to it -- I can't really rely on my search tools.
I disagree. You can rely on your search tools, as I've demonstrated in my previous reply. I feel like you're thinking of the worst case scenario and convincing yourself that it's very common. It simply isn't, people don't create crazy identifiers, why would they?
> So that... when you're using a library you can refer to its identifiers using a different capitalization convention if you want to--why is that important?
It's important for consistencies sake. In the real world developers prefer different conventions, so you undoubtedly run into a library which uses a convention that is different to your own. It's nice to be able to call that libraries functions in the same convention as your own.
I agree that it's not a huge advantage, which is why I created this thread on the Nim forum recently: https://forum.nim-lang.org/t/4388. My main reason to consider getting rid of it though is people like yourself who dismiss the whole language because of this small feature :(
It has a lot in common with Nim, but is backed by a much larger community. Its FFI interface for C functions is faster than...C.
If Julia doesn't fit your use case(s), Rust might also be worth a look. What worries me about Rust is that it looks to me to have an awful lot of boilerplate that detracts from readability.
If you had your own preference one way or the other, you could call a library's `snake_case(foo)` function as `snakeCase(foo)` instead, and pretend that the library matched your own personal style.
Of course, this isn't very useful in practice, and makes simple things like grepping for identifiers or Googling a function that much harder. Tools for refactoring also suffer.
What's better is having a single style guide enforced by ordained tooling; e.g. PEP 8 for Python, Prettier for JavaScript, or gofmt for Go.
Nim on the other hand takes a different approach, don't trust anyone else to keep things the way you like it, but rather allow you to use it however you want. This means that if some inexperienced Nim programmer who didn't care to look at the NEP 1 style guide (yes Nim also has a style guide, which says Nim prefers camelCase), but nonetheless wrote an interesting library could still see his library used by others.
If everyone is using this tool anyway then style insensitivity will not be a problem, and for those cases where some library uses snake_case instead the code formatter will still be able to format your code completely consistently even if you're using that library. There is no way that gofmt or any other language's code formatter can do that.
This is such an incredibly small inconvenience, I have no idea why the Nim language would choose to make identifiers case/_ insensitive. Basic refactoring tools become unnecessarily more complicated.
Just searching for an identifier is a complex regex instead of what should just be ctrl+f.
"Basic refactoring tools" would just need to replace the case sensitive search with insensitive. Every editor knows how to do that.
If you're talking about the underscore and first letter rules - yes, they're different, and that's why nim includes nimgrep, and support was added for just about every editor under the sun already (Emacs, VSCode, Vim, Sublime, TextMate at the very least). It's still Ctrl+F
https://docs.python.org/2/library/queue.html
Before 2.6, the situation was even worse, with camel-case methods in the threading module:
That's something that would have appealed to me years ago, but now not so much.
In 2018, I want all the libraries, and all the code I ever look at in a language to follow the same style and naming conventions. If you adapt yourself to that, my belief is that will aid comprehension in the long term.
So I appreciate the language communities which have strong conventions which are followed by the majority, and are encouraged / enforced by the tooling. All hail gofmt and rustfmt!
It's way too easy to ignore (or even embrace) the identifier equality rules in Nim to make this the hill you die on. My story's very similar to other responses - I've been using Nim for quite a while and these identifier rules have never been an issue.
I strongly suggest anyone hung up on this monster under the bed try Nim anyway as it's really pleasant to use. It's sad that all Nim's benefits are sometimes drowned by mostly unfounded hangups on this identifier thing.
Anyway, don't worry: I didn't die on that hill. I've had the opportunity to spend some more time on Nim since.
There was a set amount of time available to spend on Nim at that point, and all that time went into finding out why nimgrep exists in the first place, then reading up on the background.
It didn't help that all nimgrep's documentation had to say on the matter was "Nimgrep has particularly good support for Nim's eccentric style insensitivity", which doesn't really tell you anything unless you already know about Nim's style insensitivity.
I've seen people write wrappers just to fix casing.
EDIT: you can still change them in importc pragmas, but this still seems less nice to me.
Still, you can reuse Nim libs even if they don't follow nep1: one can still use nimpretty/gofmt for his own codebase.
Using name completion in my editor is enough to keep the naming consistent. Try the language for a month before deciding.
Also, the survey indicates that very few people are turned off by this feature:
https://nim-lang.org/blog/2018/10/27/community-survey-result...
Because it's effectively a transpiler and it's way less opinionated than (say) Rust, I managed to use nim in embedded controllers without any special support from the compiler.
Nim suffers because it doesn't have the big push of a corporation such as Mozilla behind.
- Nim JS for browser display
- Nim C as a backend
In other words, Nim is not a transpiler, it's a compiler that outputs C or Javascript. But the difference is just in terms of the readability and modifiability of the output. For the purpose of using it in embedded controllers, the difference doesn't matter, it's the fact that it generates C code that is of value. And yes, Nim is vastly less "opinionated" than Rust, thank goodness.
I personally believe that they aren't. But I know of a lot of people who disagree.
And there are people who will disagree about just about anything, because they are ill informed or have poor judgment or are dishonest (looking at you, White House) ... the mere fact that there are people who disagree about something is not of significance.
Of course not :)
Yeah, to me Nim is a compiler. However, I can see why people might refer to it as "transpilation" if we are talking Nim->JS. But yeah, please don't call Nim a transpiler, it makes us Nimians all sad.
In practice, even once I was able to compile basic Nim, there were a lot of glibc and other POSIX dependencies for any of Nim's standard libraries, some of which weren't available in ESP-IDF.
That's totally fair, but many of those dependencies aren't available when compiling to JS either, though, so I was surprised. In the end, delving into the code I found that a lot of stuff was gated behind the equivalent of "platform=JS" switches throughout the stdlib. It seemed like adding support for another platform would be a major pain.
This was all preliminary investigation and I didn't reach out to the Nim community, so perhaps I missed something. Maybe this kind of portability isn't even a goal for Nim. It would definitely be nice to have, though.
Here are some libraries for embedded you can get inspiration from[1]:
- msp430f5510 - Run Nim on MSP430f5510 micro-controller (6KB of RAM).[2]
- stm32f3 - Run Nim on STM32F3 micro-controller (16KB of RAM).[3]
- ardunimo - Nim wrapper for Arduino + LinkIt ONE SDK by Mediatek.[4]
- ardunimesp - Nim wrapper for Arduino ESP8266 framework + A tool for flash, compile and make the nim project into an Arduino project.[5]
[1] https://github.com/VPashkov/awesome-nim#embedded
[2] https://gitlab.com/jalexander8717/msp430f5510-nim
[3] https://github.com/mwbrown/nim_stm32f3
[4] https://github.com/gokr/ardunimo
[5] https://gitlab.com/NetaLabTek/Arduimesp
Also, yes abstracting a platform is a lot of pain but Nim accepts PR even for niche platforms like Haiku, Genode and Nintendo Switch.
Also with the upcoming destructors, the standard library will be GC-free so much more will be usable on embedded.
--gc:stack
--header:"nim.h"
--os:standalone
--noMain
--genDeps
Looking at those projects you linked though, clearly I didn't try hard enough! Great to see that people have had success.
Disclaimer: he is also my colleague.
[1]: https://github.com/status-im?utf8=&q=&type=&language=nim
[1]: https://github.com/nim-lang/nimforum
[2]: https://github.com/dom96/httpbeast
In terms of features it's powerful enough to build a Discourse-like forum enough. In terms of performance it's very well performing in the TechEmpower benchmarks[3] it is competing in. It even grabbed first place on JSON serialization on Cloud hardware.
[3]: https://www.techempower.com/benchmarks/#section=data-r17&hw=... and https://forum.nim-lang.org/t/1152#27100
The core language is interesting, but like the standard library has an odd edge here and there.