6 ms·

Goodbye Nim, and Good Luck

51 points by Scramblejams 12y ago

dkarapetyan 12y ago
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.
- j-hernandez 12y ago
  Goodbye Discovering A Language Trade-Off and Not Dramatizing the Entire Experience, and good luck.
- chwahoo 12y ago
  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 12y ago
    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.
- luddypants 12y ago
  I'm not sure this blog post could have been any less dramatic. He could have not written it I suppose, but he brings up valid points that are probably useful for everyone who might be using or interested in Nim. I don't think the attitude here should be "if you don't have anything good to say don't say anything at all."
- lmm 12y ago
  This might be a tradeoff - or it might simply be a flaw. Compared to a language that provides easy composition of managed state changes (Haskell or Clojure), or an alternate model for handling these kind of updates (Erlang or Scala), what is the compensating advantage that Nim gets for this tradeoff?
  - azinman2 12y ago
    Extreme portability.
    - heinrich5991 12y ago
      Why is extreme portability opposed to multithreading?
      - spb 12y ago
        Because each platform has its own wildly different threading semantics? (I don't actually know if this is necessarily true.)
- moomin 12y ago
  The problem is, there's already plenty of garbage collected mostly portable languages with slightly painful FFI.
mcguire 12y ago
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 12y ago
  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 12y ago
    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.
    - deleted 12y ago
      [deleted]
    - zokier 12y ago
      Rust documentation on concurrency and shared mutable state might help: http://doc.rust-lang.org/book/concurrency.html#safe-shared-mutable-state http://doc.rust-lang.org/book/concurrency.html#safe-shared-m... and http://doc.rust-lang.org/nightly/intro.html#concurrency http://doc.rust-lang.org/nightly/intro.html#concurrency
    - nercury 12y ago
      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.
perturbation 12y ago
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.

51 points by Scramblejams 12y ago

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.

j-hernandez 12y ago
Goodbye Discovering A Language Trade-Off and Not Dramatizing the Entire Experience, and good luck.
chwahoo 12y ago
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 12y ago
  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.
luddypants 12y ago
I'm not sure this blog post could have been any less dramatic. He could have not written it I suppose, but he brings up valid points that are probably useful for everyone who might be using or interested in Nim. I don't think the attitude here should be "if you don't have anything good to say don't say anything at all."
lmm 12y ago
This might be a tradeoff - or it might simply be a flaw. Compared to a language that provides easy composition of managed state changes (Haskell or Clojure), or an alternate model for handling these kind of updates (Erlang or Scala), what is the compensating advantage that Nim gets for this tradeoff?
- azinman2 12y ago
  Extreme portability.
  - heinrich5991 12y ago
    Why is extreme portability opposed to multithreading?
    - spb 12y ago
      Because each platform has its own wildly different threading semantics? (I don't actually know if this is necessarily true.)
moomin 12y ago
The problem is, there's already plenty of garbage collected mostly portable languages with slightly painful FFI.

mcguire 12y ago

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 12y ago
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 12y ago
  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.
  - deleted 12y ago
    [deleted]
  - zokier 12y ago
    Rust documentation on concurrency and shared mutable state might help: http://doc.rust-lang.org/book/concurrency.html#safe-shared-mutable-state http://doc.rust-lang.org/book/concurrency.html#safe-shared-m... and http://doc.rust-lang.org/nightly/intro.html#concurrency http://doc.rust-lang.org/nightly/intro.html#concurrency
  - nercury 12y ago
    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.

perturbation 12y ago

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.