Learn X in Y minutes Where X=Nim
learnxinyminutes.com
learnxinyminutes.com
[0] - http://howistart.org
I can see clearly where I might draw a line of delineation between where I select Go vs. say, Rust, but I'm not as clear where that line is for Go vs. Nim.
Does anyone have any enlightening thoughts on that?
https://github.com/dom96/jester/blob/master/readme.markdown
I think that there's a lot of overlap for the types of problems that can be solved by either, but I like writing in Nim more than I like writing in Go.
Go is a GC'ed language and that's that. Like any other GC'ed language, the treatment for GC woes is palliative.
Rust is designed around no GC and that's that. Of course, Rust did at one point have a baked in GC and it can be used with a GC, but you need to fully understand the Rust way of doing things and will always be working with the borrow checker in mind.
Nim's GC is special in comparison to mainstream GC'ed languages as it offers you great control. For ease of development it is a GC'ed language, yet for performance and ABI purposes allows deterministic GC. It seems to offer the ultimate in flexibility and expressiveness at the cost of footguns and complexity.
Unless you need to GC pointers shared between multiple threads, in which case your only option is the Boehm GC (which is imprecise, unlike Go's). This is a significant disadvantage in both expressiveness and safety that Go does not possess.
- I have a large graph data structure allocated in one thread and I want to transfer it to another thread without copying.
- I have a lock-free data structure and I want the benefits of a GC so I don't have to use less efficient hazard pointers [1].
- I have an in-memory database that I want to be able to query efficiently from multiple threads without copying.
- I'm doing work stealing on a large, complex data structure and I need to be able to access pieces of that data structure from multiple threads with unpredictable memory access patterns.
- I'm using a multicore job queuing system (like most AAA games do nowadays) and almost all game assets can be accessed from any thread.
These are just a few. Sure, you can use unsafe manual memory management to work around it, but without RAII and a library designed for manual memory management you suffer a huge penalty in usability—not to mention the safety problems. I can foresee people easily ending up in a situation whereby they can't multithread their applications because they started out using the GC and would have to rewrite all their code to switch from automatic memory management to unsafe manual memory management.
Another way to work around the restriction is to copy the data, but that usually ends up making your parallel algorithm slower than sequential unless it has very high arithmetic intensity. (This is based on experience.)
Some people need these kind of optimisations all the time.
Most people don't need them even once in their entire life.
And it's not a question of optimization, it's a question of semantics. Performing an operation in a background thread with a strong mutable reference to an object is a semantic concept. Without a thread-safe GC you simply can't do it.
Almost all AAA games use C++, and live with the 'joys' of manual memory management. Nim provides that as well, from what I've read. I've not yet taken the Nim plunge, but I'm looking forward to it.
Go constantly makes me jump through hoops and feels very rigid in its religious beliefs ("Thou shalt not want exceptions, thou shalt not want generics!").
Many of the syntax and capitalisation rules seem arbitrary, different for the sake of being different. I don't like the way Go code looks, even after using it for a while.
Nim feels less pretentious overall. The syntax is familiar and pleasant to me, mimic'ing languages that I like (Ruby/Python). It packs most of the little conveniences (exceptions, generics, short-hand iterators etc.) that Go stripped for the sake of "purity".
I've said it before: I hope for Nim to become the next (and faster) Ruby/Python, at which point it will very likely replace Go for me.