Nim 1.4
nim-lang.org
Nim 1.4
1–10 of 144 posts
Re: Nim 1.4
#2Great stuff! GC ORC is an amazing improvement over existing memory management models :) I hope to see more Nim projects adopt it!
Re: Nim 1.4
#3There are a lot of gotchas with the new GC that make me nervous about this release:
> As far as we know, ARC works with the complete standard library except for the current implementation of async...
That's not a great endorsement...
> If your code uses cyclic data structures, or if you’re not sure if your code produces cycles, you need to use --gc:orc and not --gc:arc.
Seems like this is a big onus to put on the user -- it's tough to prove a negative like this.
Re: Nim 1.4
#4There are a lot of gotchas with the new GC that make me nervous about this release: > As far as we know, ARC works with the complete standard library except for the current implementation of async... That's not a great endorsement... > If your code uses cyclic data structures, or if you’re not sure if your code produces cycles, you need to use --gc:orc and not --gc:arc. Seems like this is a big onus to put on the use…
Looks like it'a still an opt-in experimental option at this point rather than the default. Preaumably they'll fix these caveats before recommending it for general use.
Re: Nim 1.4
#5There are a lot of gotchas with the new GC that make me nervous about this release: > As far as we know, ARC works with the complete standard library except for the current implementation of async... That's not a great endorsement... > If your code uses cyclic data structures, or if you’re not sure if your code produces cycles, you need to use --gc:orc and not --gc:arc. Seems like this is a big onus to put on the use…
Sorry if you got misled by the article - ORC is what you should use if your program has cycles. ORC deals with async just fine.
Re: Nim 1.4
#6Great to see that Nim grows ever faster and more stable. Been a fan of the language for quite a while now and while I miss the old days of new and exiting changes with every release it's much easier to target Nim now that it has become this stable. Great work all around!
Re: Nim 1.4
#7There are a lot of gotchas with the new GC that make me nervous about this release: > As far as we know, ARC works with the complete standard library except for the current implementation of async... That's not a great endorsement... > If your code uses cyclic data structures, or if you’re not sure if your code produces cycles, you need to use --gc:orc and not --gc:arc. Seems like this is a big onus to put on the use…
Looks like it'a still an opt-in experimental option at this point rather than the default. Preaumably they'll fix these caveats before recommending it for general use.
If I recall correctly, I read that the intention is to eventually make ORC the default, not ARC. (ORC is like ARC, but it avoids problems with cycles.)
Re: Nim 1.4
#8There are a lot of gotchas with the new GC that make me nervous about this release: > As far as we know, ARC works with the complete standard library except for the current implementation of async... That's not a great endorsement... > If your code uses cyclic data structures, or if you’re not sure if your code produces cycles, you need to use --gc:orc and not --gc:arc. Seems like this is a big onus to put on the use…
I think you missed this detail:
> ARC was first shipped with Nim 1.2... [ORC is] our main new feature for this release
Seems like they should phrase it like "use ORC unless you know you don't have cycles" rather than "use ORC if you're not sure you have cycles", but that's a reasonable responsibility to take on if you're choosing to use an alternative garbage collector.
Re: Nim 1.4
#9Earlier quoted context omitted.
Looks like it'a still an opt-in experimental option at this point rather than the default. Preaumably they'll fix these caveats before recommending it for general use.
If I recall correctly, I read that the intention is to eventually make ORC the default, not ARC. (ORC is like ARC, but it avoids problems with cycles.)
Yes, you're totally right! That's the exact reason ORC should eventually become the new default GC.
Re: Nim 1.4
#10There are a lot of gotchas with the new GC that make me nervous about this release: > As far as we know, ARC works with the complete standard library except for the current implementation of async... That's not a great endorsement... > If your code uses cyclic data structures, or if you’re not sure if your code produces cycles, you need to use --gc:orc and not --gc:arc. Seems like this is a big onus to put on the use…
I believe the phrasing might not be clear to everyone, so here's a reduced version:
* Nim's current async implementation creates a lot of cycles in the graph, so ARC can't collect them.
* ORC is then developed as ARC + cycle collector to solve this issue, and it has been a success.
* This 1.4 release introduces ORC to everyone so that we can have mass testing for this new GC and eventually move torwards ORC as the default GC.
TL;DR: ORC works with everything† and will be the new default GC in the future. Your old Nim code will continue to work, and will just get faster‡.
† We are not sure that it's bug-free yet, which is why it's not the default for this release.
‡ Most of the time ORC speeds things up, but there are edge cases where it might slow things down. You're encouraged to test your code with --gc:orc against our default GC and report performance regressions.