For now it's an alternative to the `--gc:none` mode with the difference that the full stdlib can work with it (eventually) without leaking memory. Once we achieved this (and we haven't!) we can decide on the next steps -- it's my hope that most libraries will follow the stdlib's example and work with the --newruntime so that the GC-decision can be left to the Nim application programmers. But we'll see, please relax, I'm not mad.
- Re: Nim's future: GC and the newruntime Sixte
- Re: Nim's future: GC and the newruntime Araq
- Re: Nim's future: GC and the newruntime rayman22201
- Re: Nim's future: GC and the newruntime cdome
- Re: Nim's future: GC and the newruntime andrea
- Re: Nim's future: GC and the newruntime cdome
- Re: Nim's future: GC and the newruntime Araq
- Re: Nim's future: GC and the newruntime cdome
- Re: Nim's future: GC and the newruntime Araq
- Re: Nim's future: GC and the newruntime Akito
- Re: Nim's future: GC and the newruntime Araq
- Re: Nim's future: GC and the newruntime GordonBGood
- Re: Nim's future: GC and the newruntime Araq
- Re: Nim's future: GC and the newruntime Sixte
- Re: Nim's future: GC and the newruntime Araq
- Re: Nim's future: GC and the newruntime GordonBGood
- Re: Nim's future: GC and the newruntime Sixte
- Re: Nim's future: GC and the newruntime Sixte
- Re: Nim's future: GC and the newruntime Araq
