
Goodbye Nim, and Good Luck - Scramblejams
https://gradha.github.io/articles/2015/02/goodbye-nim-and-good-luck.html
======
dkarapetyan
So it doesn't fit his use case. There is no silver bullet. Everything is a
moneky's paw in software engineering. I look forward to the day when someone
discovers a language trade-off and doesn't dramatize the entire experience.

~~~
chwahoo
I like reading a bit of prose about when a tool doesn't fit someone's use
case. Nim has a pretty interesting approach to data sharing in concurrency,
and it's more interesting to read a story of someone who got bit by it than to
read a table of language features and wonder when it might prove to be a
problem.

~~~
dkarapetyan
But that's not how it was phrased at all. It was more like "I liked this
thing, then I didn't like it because it didn't scale in a certain aspect as I
wanted to so peace". I think studies of use cases are valuable but this was
not one.

------
perturbation
Shame to see gradha go - I read and enjoyed his ranty posts on macros, and
he's contributed to a lot of repos.

He is right that there was some breakage in libraries with 0.96 to 0.10.2 -
I'm hoping that things will start to settle once v1.0 is released and Nim will
gain more traction.

------
mcguire
Might I suggest looking at Rust? It started out with the policy that

" _This means that a thread cannot touch the memory of another thread._ "

but has grown a host of smart pointer-based thingys that do exactly that.

~~~
pcwalton
As far as I'm aware, Rust is the _only_ recent systems programming language
that is memory-safe in parallel mode (i.e. number of kernel threads > 1). Java
and C# were, by virtue of spending a lot of impressive work on their garbage
collectors, but the recent languages have unfortunately tended to throw memory
safety away in various cases.

(Edit: I realized I forgot Swift -- mea culpa.)

~~~
eatonphil
Not that I don't believe, but can you provide a citation for that fact about
Rust in parallel mode? I don't follow Rust too closely, but I hadn't heard of
that. That is really interesting.

~~~
nercury
Interesting read would be here: [http://doc.rust-
lang.org/std/thread/](http://doc.rust-lang.org/std/thread/)

It is also guaranteed by ownership system: in the safe mode (which is default)
rust will statically (at compile time) ensures that a value can only be
mutated at a single execution point. It is done by moving, instead of copying
any value _by default_, unless it is wrapped in some kind of synchronization
primitive or implements a _Copy_ trait.

Synchronization primitives themselves are implemented in unsafe mode, thus
limiting the unsafe code scope and allowing custom unsafe code which can also
be wrapped in safe interface.

