12 ms·

Very interesting. Is the memory model essentially a middle ground between GC-based and manual memory management?: > Scope-based memory management (destructors

Very interesting. Is the memory model essentially a middle ground between GC-based and manual memory management?: > Scope-based memory management (destructors are injected after the scope) - generally reduces RAM usage of the programs and improves performance. How does Nim handle references? How similar is this to Rust's lifetimes GC-ed instead of manually managed? Is this essentially like Rust, with the main difference that lifetimes (references) are handled via reference counting? > Shared heap - different threads have access to the same memory and you don’t need to copy variables to pass them between threads - you can instead move them I think this is the same as Rust thread move semantics?

ampdepolymerase 6y ago
Swift
planetis 6y ago
Previous discussion: https://news.ycombinator.com/item?id=25345770 https://news.ycombinator.com/item?id=25345770
didibus 6y ago
Seems Nim will do some static analysis where if it can infer a reference is locally scoped in some way, it will deterministically inject a call to the destructor at the end of the scope. If not, it will do reference counting which will also have (if using orc) an extra cycle detection pass so that the references count references can also handle cycles. Finally, Nim will also do some static analysis, and if it can infer that even though a reference is passed to something else, if it can tell that it isn't used afterwards from the previous place, instead of copying the data, it will share it, bit since it's not used by the previous owner you can think of it as moving it rather then sharing it. If Nim can't be sure this is the case or sees it isn't, then data will be copied. That's what I understood at least. So ya, it does look like some kind of hybrid between statically inferable ownership semantics, reference counting, ARC and GC.
- k__ 6y ago
  So if I understand that correctly: Nim will try to do a light version of Rust's borrow checking and then gradually move from static to dynamic solutions for memory management. I read that Nim's GC is optional, does this mean it can be deactivated and when the static memory management fails, I can do it manually for the edge cases that would otherwise done by the GC? Hope this makes sense, haha.
  - beagle3 6y ago
    > does this mean it can be deactivated? Sort of. You either deactivate it completely with --gc:none ; or, you do it on per-variable basis by using a "ptr" (pointer) type, which is outside of the GC's realm. Any variable declared "ref" (reference) is within the realm of Nim's GC, and will be tracked by the gc you chose (none, boehm, mark&sweep, arc, orc, ...). Additionally, you can define type bound operators to help the GC do its job, but IIRC (and I'm not sure I understand correctly), that doesn't turn off arc/orc - rather, it tells them how to apply some things.
  - didibus 6y ago
    > So if I understand that correctly: Nim will try to do a light version of Rust's borrow checking and then gradually move from static to dynamic solutions for memory management I think that's an okay way to put it. Though it might be best to think of it the other way around. It'll default to GC and copying data around (pass by value) and will try to optimize things if it can to more deterministic memory management and pass by reference. > I read that Nim's GC is optional, does this mean it can be deactivated and when the static memory management fails, I can do it manually for the edge cases that would otherwise done by the GC? It isn't optional like that. It's more that by default all data is passed by value and allocated on the stack. And if you want to create things on the heap, you need to be explicit about it, at which point you can choose if you want the pointer to be managed by Nim's GC or manually. That's done by having two type of pointers, ref will be under GC, and ptr won't.
    - pjmlp 6y ago
      Which in the Cedar/Oberon/Modula-2+/3 family is known as REF and UNTRACED REF.
pjmlp 6y ago
Reference counting with cycle collectors is a well known algorithm, nothing new. Environments like Mesa/Cedar at Xerox PARC already made use of it, back in 1985. https://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc/techReports/CSL-84-7_On_Adding_Garbage_Collection_and_Runtime_Types_to_a_Strongly-Typed_Statically-Checked_Concurrent_Language.pdf https://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc...
- planetis 6y ago
  (I can't see the link, its offline) the difference is though, there is no expensive heap scans. That is new (it's called "trial deletion", see the Bacon paper) and makes it "deterministic" due to that, independently from the heap size and suitable for hard real-time systems https://nim-lang.org/blog/2020/12/08/introducing-orc.html https://nim-lang.org/blog/2020/12/08/introducing-orc.html
  - pjmlp 6y ago
    Here is a working link from archive.org https://archive.org/details/bitsavers_xeroxparctddingGarbageCollectionandRuntimeTypestoa_1765837 https://archive.org/details/bitsavers_xeroxparctddingGarbage...
nimmer 6y ago
Nim has multiple memory management strategies with very different trade-offs. ORC provides performance comparable to Rust but without having to write the boilerplate. https://nim-lang.github.io/Nim/gc https://nim-lang.github.io/Nim/gc https://nim-lang.org/blog/2020/12/08/introducing-orc.html https://nim-lang.org/blog/2020/12/08/introducing-orc.html

ampdepolymerase 6y ago

Swift

planetis 6y ago

Previous discussion: https://news.ycombinator.com/item?id=25345770 https://news.ycombinator.com/item?id=25345770

didibus 6y ago

Seems Nim will do some static analysis where if it can infer a reference is locally scoped in some way, it will deterministically inject a call to the destructor at the end of the scope. If not, it will do reference counting which will also have (if using orc) an extra cycle detection pass so that the references count references can also handle cycles. Finally, Nim will also do some static analysis, and if it can infer that even though a reference is passed to something else, if it can tell that it isn't used afterwards from the previous place, instead of copying the data, it will share it, bit since it's not used by the previous owner you can think of it as moving it rather then sharing it. If Nim can't be sure this is the case or sees it isn't, then data will be copied. That's what I understood at least. So ya, it does look like some kind of hybrid between statically inferable ownership semantics, reference counting, ARC and GC.

k__ 6y ago
So if I understand that correctly: Nim will try to do a light version of Rust's borrow checking and then gradually move from static to dynamic solutions for memory management. I read that Nim's GC is optional, does this mean it can be deactivated and when the static memory management fails, I can do it manually for the edge cases that would otherwise done by the GC? Hope this makes sense, haha.
- beagle3 6y ago
  > does this mean it can be deactivated? Sort of. You either deactivate it completely with --gc:none ; or, you do it on per-variable basis by using a "ptr" (pointer) type, which is outside of the GC's realm. Any variable declared "ref" (reference) is within the realm of Nim's GC, and will be tracked by the gc you chose (none, boehm, mark&sweep, arc, orc, ...). Additionally, you can define type bound operators to help the GC do its job, but IIRC (and I'm not sure I understand correctly), that doesn't turn off arc/orc - rather, it tells them how to apply some things.
- didibus 6y ago
  > So if I understand that correctly: Nim will try to do a light version of Rust's borrow checking and then gradually move from static to dynamic solutions for memory management I think that's an okay way to put it. Though it might be best to think of it the other way around. It'll default to GC and copying data around (pass by value) and will try to optimize things if it can to more deterministic memory management and pass by reference. > I read that Nim's GC is optional, does this mean it can be deactivated and when the static memory management fails, I can do it manually for the edge cases that would otherwise done by the GC? It isn't optional like that. It's more that by default all data is passed by value and allocated on the stack. And if you want to create things on the heap, you need to be explicit about it, at which point you can choose if you want the pointer to be managed by Nim's GC or manually. That's done by having two type of pointers, ref will be under GC, and ptr won't.
  - pjmlp 6y ago
    Which in the Cedar/Oberon/Modula-2+/3 family is known as REF and UNTRACED REF.

pjmlp 6y ago

Reference counting with cycle collectors is a well known algorithm, nothing new. Environments like Mesa/Cedar at Xerox PARC already made use of it, back in 1985. https://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc/techReports/CSL-84-7_On_Adding_Garbage_Collection_and_Runtime_Types_to_a_Strongly-Typed_Statically-Checked_Concurrent_Language.pdf https://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc...

planetis 6y ago
(I can't see the link, its offline) the difference is though, there is no expensive heap scans. That is new (it's called "trial deletion", see the Bacon paper) and makes it "deterministic" due to that, independently from the heap size and suitable for hard real-time systems https://nim-lang.org/blog/2020/12/08/introducing-orc.html https://nim-lang.org/blog/2020/12/08/introducing-orc.html
- pjmlp 6y ago
  Here is a working link from archive.org https://archive.org/details/bitsavers_xeroxparctddingGarbageCollectionandRuntimeTypestoa_1765837 https://archive.org/details/bitsavers_xeroxparctddingGarbage...

nimmer 6y ago

Nim has multiple memory management strategies with very different trade-offs. ORC provides performance comparable to Rust but without having to write the boilerplate. https://nim-lang.github.io/Nim/gc https://nim-lang.github.io/Nim/gc https://nim-lang.org/blog/2020/12/08/introducing-orc.html https://nim-lang.org/blog/2020/12/08/introducing-orc.html