> What I would be interested in more is features/bugs that are preventing you > from using Nim as your main language, and require backwards incompatible > changes to fix.
I think I did answer that question, but in case it wasn't clear: > * void / null safety (as in Eiffel or Kotlin; the current pointer proposal > doesn't address that) > * design-by-contract (with support in compiling and debugging, as in Eiffel > and Ada 2012 / SPARK 2014) > I don't think you can concentrate on those at the moment, so I don't expect you to. The change in heap management was the one thing that really gave me pause, because people had sung the old system's praises so thoroughly that I had the impression it was unique to Nim, and worked without a hitch. Then Araq proposed the new model & while he by no means trashed the old setup, it became clear that everyone had been quiet about some really serious problems. Araq's points on this have all been very well-laid out and it's a good thing he's doing them; it impressed me quite a bit. But it did drive home the point that there are some other very mature, tried and true languages that address these problems, and while I do want to use Nim, it isn't quite ready for me.
