Won't this necessitate a standard library rewrite for Nim 2.0?



As far as I understand, a split in the standard library is undesirable. And even if an opt-in GC is there for those who want it, it makes sense for the standard library to be able to work without GC. And by extension, for most of the third-party library ecosystem.

I honestly find the prospect of a new GC free language exciting, if it's somewhere in between "shoot yourself in the foot" C/C++ and "anal-retentive, take ages to compile" Rust. But wondering where this leaves early adopters and yourselves when it comes to the code already written? What's the plan?

2018-04-14 16:16:47

Good questions, well my priority is still to get v1.0 out.

The v2 stuff is pretty far in its design (not in its implementation though) in my opinion and most libraries will be easy to port. Consider this, the only thing that is not possible without the GC are complex object graphs with cycles (otherwise ref can be mapped to C++'s shared_ptr, for example). That affects many programs in Nim, no doubt, but not as many libraries. Here are some examples of modules that will be very easy to port:

  • strutils
  • times
  • osproc
  • os
  • re
  • wrappers for e.g. GTK or any other C/C++ based library that does without a GC
  • interfacing with python
  • every parser in the stdlib
  • json
  • net
  • (async)httpclient
  • math

In fact, the worst offender here is async with its hidden nested callbacks that produce a ton of cycles. But we have a solution for that already, we know when the task leaves the event loop and was completed. That's when we can free stuff deterministically. In practice it will be more painful of course, but at least on paper things look really good.

2018-04-14 17:45:19
Thanks, that sounds reassuring, although some mixed feelings remain. 2018-04-15 12:12:33