> Nim is a very good language that actually accomplishes the simplicity Go wanted imo.
Coincidentally, I just looked at Nim this evening, wrote some code and came away with the opposite impression. I'll copy-paste my sort-of-blogpost on this from [1]:
Nim itself feels a lot unlike Go and, interestingly, a lot like C++:
1. Non-orthogonal features. In C++, there are references, which are like pointers, but not quite, so you always have to think about which one to use. In Nim, non-orthogonal features include tuples vs. objects, and sequences vs. openarrays.
2. Feature creep. Just look at the language manual [2]: generic functions, type classes, 10 calling conventions (10!), garbage collection (not sure if optional or not), inline assembler, operator overloading, exceptions, an effect system, AST macros. Name any contemporary programming language feature, chances are that Nim has it.
Then there's the documentation. The language manual [2] is okay-ish, considering the size of the language. But when I dive into the library reference, the built-in module "system" [3] is so outlandishly huge and the documentation so badly formatted that it takes a lot of hunting to find what's in this module (and what isn't). Just look at all the duplicate entries in the navigation bar on the left. The system module should definitely have been split into multiple modules for the multiple concerns it covers, possibly with reexports in the actual "system" module to make sure they're all imported by default. Some parts should just be moved out of it, for example the whole file IO business belongs into "os" IMO.
Another thing that concerns me about the standard library is how many duplication is going on in there. There are at least 4 different XML parser AFAICS, and two regular expression libraries, both based on the same backend (pcre). This might be the same confusion that most languages suffer from in their pre-1.0 stabilization phase, but especially then, it's a strong argument not to use the language in production pre-1.0.
The thing that really killed it for me that I was able to produce SIGSEGV by accident, without the compiler warning me about it. I think I wrote something along the lines of:
type Config = tuple
someSetting: string
anotherSetting: string
proc readConfigFile(path: string): Config =
var file = open(path)
defer: file.close()
# TODO: implement the rest
var cfg: Config
return cfg
var cfg = readConfigFile("./example-config")
echo(cfg.someSetting) # this produces a SIGSEGV; probably because
# the memory backing `cfg` is not initialized
In 2016, I expect any new language to warn me about (or outright refuse to compile) code that might access uninitialized memory or do any other unsafe stuff, especially for a program that will run as root.
[1] https://github.com/holocm/holo/issues/8#issuecomment-2412822...
[2] http://nim-lang.org/docs/manual.html
[3] http://nim-lang.org/docs/system.html