Hello guys. I'm one of the core Nim developers, together with Araq (the creator of Nim) who should also be hanging around this thread. Feel free to ask us anything.<p>This submission is likely the result of the recent livestreams that myself and Araq have been making. You can check out my past livestreams[1] and Araq's[2] at the links below. If you're into watching us live the next time we create a livestream then follow d0m96 (<a href="https://go.twitch.tv/d0m96" rel="nofollow">https://go.twitch.tv/d0m96</a>) and araq4k (<a href="https://go.twitch.tv/araq4k" rel="nofollow">https://go.twitch.tv/araq4k</a>) on Twitch.<p>1 - <a href="https://www.youtube.com/watch?v=UQ4RvUlXIDI&index=3&list=PLm-fq5xBdPkrMuVkPWuho7XzszB6kJ2My" rel="nofollow">https://www.youtube.com/watch?v=UQ4RvUlXIDI&index=3&list=PLm...</a><p>2 - <a href="https://www.youtube.com/watch?v=E2qlDKm_WzE" rel="nofollow">https://www.youtube.com/watch?v=E2qlDKm_WzE</a>, <a href="https://www.youtube.com/watch?v=UV38gQfcb9c" rel="nofollow">https://www.youtube.com/watch?v=UV38gQfcb9c</a>
I’m not a huge fan of the modern C++ style that obsessively avoids null pointers and instead uses object references that are created in an invalid/empty state. With a pointer there is a single way to represent “nothing”, regardless of what the object represents. With a reference I have to go read the API to understand the “nothingness” states.<p>Also, when you’re thinking in pointers, it’s easy to add levels of indirection with the same mental tools (pointers to pointers, etc.) Personally I find it’s easier to solve problems with a limited orthogonal toolset than a sprawling array of marginally differently balanced optimizations, which is what most of C++ has become.
Completely off-topic, bit I feel compelled to mention this: The timestamping of this article is exemplary.<p>Even if it only showed a date, and no time, the time zone is relevant. The Internet is supposed to be for the whole world, not just one time zone.
Does this mean that Nim 1.0 will be postponed even further?<p>That's OK, it's better to get it right, and it's still useful for small projects in the meantime. But Nim seems like a language that is never truly finished.<p>I like this direction. I tried to avoid "ref" in my last Nim project, but it's too hard to do that for every type the way the language is currently designed.
I'm a C++ dev and this sounds extremely interesting. I have nim a spin a year ago and really liked what I saw, but GC was a real issue because I'm doing audio development where you end up having to circumvent the GC anyway. I would love to allow my users to create MIDI plugins with nim and this is a key step towards that.
The syntax and title reminds me of standard Pascal, which has very constrained pointers that, among other things, you can't do arithmetic with --- eventually leading to code that basically reinvents memory itself by using a large array and lots of indexing operations.<p>(Look at Donald Knuth's TeX for an example of this style.)
First let me say that I'm not familiar with Nim. But I understand that it compiles/transpiles to C/C++. And it sounds like they're now trying to move away from dependency on the GC. In that case, might I suggest they consider switching the transpile target to SaferCPlusPlus[1]. It might make things easier as it already addresses the "efficient memory-safety via scope lifetimes without a borrow-checker" issue. And also the (data race) safe sharing of objects between threads. (Note that the documentation is currently rather out-of-date, and a major update is coming.)<p>[1] shameles plug: <a href="https://github.com/duneroadrunner/SaferCPlusPlus" rel="nofollow">https://github.com/duneroadrunner/SaferCPlusPlus</a>
The other year I tried to implement a GC on top of an existing scripting language to handle circular dependency cases. A big problem however was the existing system for referencing objects wasn't particularly well designed for this particular case (e.g. no roots, no thread safety), and I couldn't come up with a solution I found satisfactory and fool-proof.<p>The fact the author had so many problems with GC bugs is somewhat reassuring. Would be interesting to see a GC-less Nim in a production use-case.