I have used Nim heavily for more than a year now, and it turned out to be the most productive language I have every used. Nim could be considered a modern Lisp with infix notation and Python like syntax with native C performance. The macro system is incredibly well designed and easy to handle.
I also tried Rust, and it turned out to be much more complicated and time consuming. I would use it for systems programming only. Redox is the only reason for me to learn Rust.
> The one thing is its rule for when two identifiers are the same.
First it looked strange to me as well. However there are actually good reasons to avoid case sensitivity.
As for the user_sort and use_rsort example, such semantic errors can easily be fixed by qualification (a.user_sort and b.use_rsort). Errors like the following one however are very hard to fix in case sensitive languages like C++ and probably even Rust:
hmm ... smart_func(a,b) doesn't work. Seems to be a typo. Which function did the author really mean?
Nim would reject such a mess in general.
The developers of Nim have implemented a lot of nice features. A really silly idea however are strong spaces. No serious developer would ever use such a dangerous "feature". It should be removed from Nim.
> Errors like the following one however are very hard to
> fix in case sensitive languages like C++ and probably
> even Rust
No, in Rust the compiler will emit a style warning if you have a function whose name includes capital letters. This can be toggled off (and also elevated into a hard error), but it's always on by default.
Furthermore, when you import a module Rust keeps it namespaced under the module's name, so you never need to worry about names accidentally colliding or being unsure as to where a symbol comes from. You have to use an explicit glob import to pull in all of a module's public items into the current namespace.
Furtherfurthermore, Rust warns when you import a symbol and then don't use it, so even if you name all of these functions differently and ignore the style warnings and glob-import the modules, then you'll get yet another warning when you fail to ever use two of the symbols.
Furtherfurtherfurthermore, Rust doesn't allow symbols with the same name to exist in the same namespace, so even if you went back and fixed all those functions to comply with the style warnings, you'd get compilation errors if you continued to glob-import any of the two of them.
> there are actually good reasons to avoid case sensitivity
My problem with Nim's identifier syntax rules are not about case-sensitivity. I have happily used case-sensitive languages and case-insensitive ones. My problem is with ignoring punctuation in identifiers.
> such semantic errors can easily be fixed by qualification
Once you notice that there's a problem. The trouble is, you might not.
> [three things with names like smart_func but different case]
Again, case-insensitivity is a red herring here as far as I'm concerned.
I have used Nim heavily for more than a year now, and it turned out to be the most productive language I have every used. Nim could be considered a modern Lisp with infix notation and Python like syntax with native C performance. The macro system is incredibly well designed and easy to handle.
I also tried Rust, and it turned out to be much more complicated and time consuming. I would use it for systems programming only. Redox is the only reason for me to learn Rust.
> The one thing is its rule for when two identifiers are the same.
First it looked strange to me as well. However there are actually good reasons to avoid case sensitivity.
http://blog.codinghorror.com/the-case-for-case-insensitivity...
As for the user_sort and use_rsort example, such semantic errors can easily be fixed by qualification (a.user_sort and b.use_rsort). Errors like the following one however are very hard to fix in case sensitive languages like C++ and probably even Rust:
main: hmm ... smart_func(a,b) doesn't work. Seems to be a typo. Which function did the author really mean?Nim would reject such a mess in general.
The developers of Nim have implemented a lot of nice features. A really silly idea however are strong spaces. No serious developer would ever use such a dangerous "feature". It should be removed from Nim.
https://github.com/nim-lang/Nim/wiki/Whitespace-FAQ