5 ms·

Nim provides you more flexibility than Go or Rust. Go is a GC'ed language and that's that. Like any other GC'ed language, the treatment for GC woes is palliati

by jakevn 12y ago

Nim provides you more flexibility than Go or Rust. 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.

pcwalton 12y ago
> 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. 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.
- dom96 12y ago
  In what situations would you need to do this? I have been using Nim for a long time now and never felt limited by this.
  - pcwalton 12y ago
    All the time. It's the bread-and-butter of high-performance concurrent programming. - 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.) [1]: http://en.wikipedia.org/wiki/Hazard_pointer http://en.wikipedia.org/wiki/Hazard_pointer
    - moe 12y ago
      All the time. Some people need these kind of optimisations all the time. Most people don't need them even once in their entire life.
      - pcwalton 12y ago
        Every Cocoa app I've written has used "[NSObject performSelectorInBackground:withObject:]", which relies on having a thread-safe GC (atomic reference counting).
        moe 12y ago
        And just as Cocoa abstracts this away from you any popular Nim frameworks that need such optimisations will also abstract them away from you.
        pcwalton 12y ago
        I don't see how. The abstraction here is automatic memory management -- i.e. the GC -- and the problem is that the abstraction doesn't work for this popular use case. The language needs to provide a more flexible abstraction: a thread-safe GC. 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.
    - ElectronCharge 12y ago
      "- 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." 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.
moe 12y ago
Some subjective thoughts: 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.

by jakevn 12y ago

pcwalton 12y ago

> 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. 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.

dom96 12y ago
In what situations would you need to do this? I have been using Nim for a long time now and never felt limited by this.
- pcwalton 12y ago
  All the time. It's the bread-and-butter of high-performance concurrent programming. - 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.) [1]: http://en.wikipedia.org/wiki/Hazard_pointer http://en.wikipedia.org/wiki/Hazard_pointer
  - moe 12y ago
    All the time. Some people need these kind of optimisations all the time. Most people don't need them even once in their entire life.
    - pcwalton 12y ago
      Every Cocoa app I've written has used "[NSObject performSelectorInBackground:withObject:]", which relies on having a thread-safe GC (atomic reference counting).
      - moe 12y ago
        And just as Cocoa abstracts this away from you any popular Nim frameworks that need such optimisations will also abstract them away from you.
        pcwalton 12y ago
        I don't see how. The abstraction here is automatic memory management -- i.e. the GC -- and the problem is that the abstraction doesn't work for this popular use case. The language needs to provide a more flexible abstraction: a thread-safe GC. 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.
  - ElectronCharge 12y ago
    "- 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." 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.

moe 12y ago

Some subjective thoughts: 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.