I was reading through the forum, and three discussions drew my mind to the topic of core language design. The question on async runtime like a Go coroutine, Nim concurrency primitives for CPU & I/O, and Araq's reference to Turbo Pascal.
I have been programming in Nim for the last 15-16 months, and obviously enjoying how hackable it is. I've written a few production tools, and I'm now writing an experimental Nim API for my company's database for company-wide knowledge base (engineering domain), and want to migrate more C++ modules to Nim. Ever since Java came along, which I really really disliked, I've tended to choose programming languages based on their core architects' good tastes. Started as a teenager with Anders Hejlsberg's Turbo Pascal, continued with Delphi <-> C++ RAD, Plan 9 C, and then C#/.NET for web because of Hejlsberg, Swift for iPad thanks to Chris Lattner, and Nim because of Araq, and diving into Mojo thanks to Lattner.
Hence, I found Araq's reply about the approach he wants Nim to take for async with "Nimlody" particularly assuring. After so many years, I would really like to just use Nim and Mojo for doing the interesting stuff for different needs. One of Lattner's core goals for Mojo was to be able to control language design fully and avoid Swift's mistakes due to Apple's competing interest groups. He emphasized that Mojo will have a small, well‑defined core and let the standard library grow as a natural, idiomatic extension of that core. The idea is to have community libraries that exploit the idiomatic Mojo way, like plug-ins to the stdlib itself, and not introduce "features" or complexity to the core language. Sounds similar to Nim. All this cast my mind to the compiled languages that I've liked, and the current monstrosity of C++. My only requirement is that I want my Nim modules to be as stable as ClojureScript has been for the front-end, and for decades.
So, am I right to understand that Nim's path going forward will be a minimalistic "batteries included" approach that emphasizes composability with a lean core, and a stdlib toolchain (like proposed Nimlody) for the "batteries included" standard library? I see community libraries going the Macro route with LLMs for domain specifics (with some unpleasant outcomes), but there is at least one less talked about, manually coded major success(?) that offers complete NodeJS target in Nim without depending on the Nim stdlib at all. I haven't used it, but it seems to be quite up to date, and stable.