Glad to see about Nim Conf planning taking off, and for the event to be hosted in May. Good time, and about time there is one! The Nim ecosystem needs to stand up and shine. The language too needs to get there for multi-core SIMD, and task & data parallelism on CPUs with different kinds of P+E cores. I guess this is what Nimony is all about - higher level abstractions instead of manual/explicit code, and let the compiler be hardware aware so that the way threads & parallelism works will not require low-level task/memory management - à la Malebolgia taking cues from Weave for simpler tasks. Weave is a truly outstanding library. I'm looking forward to how yglukhov/yasync shapes up.
I think this year is particularly important in Nim's story in the way changes are happening in professional, personal use, not least because of Claude/Devstral/Codestral. The latest development over the last few months has been the maturity of Swift for C++ interop that is now in a Goldilocks zone. And Apple's work on comptime safety, and making Embedded Swift a priority starting with their own hardware and firmware, including RISC-V.
Swift's open source story has reminded me of the post on this forum recounting a tech document as "Supermarket vs Bazaar", and that Nim is like a Bazaar. The original story was "The Cathedral vs the Bazaar" documenting C# and Kotlin's developer experience. Kotlin is no Bazaar to me when it is glued to a compiler locked into an IDE of one company and no other option.
I have to stick my neck out about where it's easier for me to make a decisive case to the CMD that Nim is the best choice for our engg teams, and where it has fallen behind. Firstly, I think Nim will simply be forgotten for Deep Learning. It still can make itself super advantageous in classic ML, but DL, AI - hardly. It will simply not have the ecosystem traction like Mojo does. Mojo has been my step into serious GPU programming. I do some jolly science stuff in Taichi lang, but this is different. And I have come to be in touch with a Modular team member working on Mojo, and I think they will pretty much democratise GPU, data parallel programming. I enter it from the world of my favorite OpenCilk, and C++ stdpar using Uni Heidelberg's AdaptiveCpp. I really enjoy thinking & writing Mojo (CPU + GPU Tiles, pure functions). Nim can have its own space only if eats C++ via interop like it does with C (and Futhark).
Next is Nim vs Swift. Swift is a pleasant language, and it will likely be the C++ successor for the work we do at applications level that need C++ interop. We run research loads on Sean Baxter's Circle compiler for low-level features with C++ having a borrow-checker. Swift is a legitimate Rust competitor, and has Apple wanting to make a real case of it. Big Plus: The Swift ecosystem feels much more like a Bazaar that knows it has world class clients, and cares about ergonomics, polish, documentation. It is reflected in the cross-platform tools available for Swift itself, and for app development. The progress is non-stop. Big Minus: Standard Swift produces rather large binaries. Nim is incredibly tiny, even compared to Rust.
Where Nim still rules for me, and my team: CLI tools, TUIs, spitting out compute kernels (CPU) with metaprogramming, workstation apps, writing shared libraries using Nim's compilation options, and that Nim can become Wasm as well as JS - These superpowers need stories being told from those who have worked and shaped Nim from the beginning. I also think Nim must take advantage of Bun + Hono, while strengthening and explaining its own HTTP ecosystem (I am right now evaluating MummyX and Guildenstern).
So, that's my little bird's eye view of things. I do wish Nim goes from strength to strength without having to shout about it.
Thanks for the write-up, and I'm glad Nim still wins over Swift, a language coming from a gazillion dollar company, for your team for some use cases.
I don't agree with the way you seem to evaluate technology: "We use X until something better comes along". I mean, it's a valid position and better than "we use Java cause we always used Java" for my purposes in convincing you to switch to Nim, but I see things quite differently.
Nim and especially Nimony are about creating a timeless classic, built on my observations that imperative programming is not for machines, it's for humans. You can talk about immutability and its elegance all day long but in the end I enjoy being able to count things. It doesn't try to chase fads, it gives you an extensible, elegant, hackable programming system that you can trust. A Lisp with low level primitives, hard real-time ready, sweet infix notation and a static type system.
About GPU support and deep learning: Nim 2 already has GPU support through third-party libraries, based on Nim's macros. These will port naturally to Nimony's plugin architecture, and become more integrated in the process.
Thank you for your detailed reply. Really appreciate it. Before I clarify a few things, I will just say that I share largely the same sentiment about Nim as your pride in its creation, and it always brings out some schmunzeln when you see how fast, efficient, and portable it is.
The main motivation for my post was that it really was overdue for a Nim conf and there needs to be a renewed momentum to get the word out about what's coming along. As at this stage, Nim is very mature, and "nearly there" for it to be fully self-contained in all core primitives of modern computing. I do also hope that Nimony's choices will also make C++ interop easier.
Also that people expect too much from Nim because it can do a lot, and somehow it must be the one single language for everything. There is no such magic bullet in any engineering, and Nim is an engineering tool, and one needs a toolbox of 2-3 languages, markups, SQL, etc. to translate intent into quality software.
My first post on this forum was with that long horizon thinking, as I felt Nim could be the language for decades like C/C++. I built things around musl C and stuck with it long before Docker made it fancy. C++ is still very relevant for me. That was my intent behind comparing Nim to Swift, and Mojo. Not because I fancy something new. Also Nim, Mojo, and Swift are the only languages to save me and future engineers from Rust insanity. And I am Ok with Mojo being the sweet spot for DL, AI, and with Nim for most other things.
I will just lay out my software, hardware preferences to let people know where I'm coming from. I am big on FreeBSD, and I think future of x86 PCs is Linux and KDE (I was an early SUSE developer during KDE 3.x days. Pardon my bias.). I have had a Tenstorrent QuietBox installed for our team because Jim Keller is my hero, and I like everything about his approach with RISC-V, PDKs for Fabs in Japan with Rapidus, etc. So, my personal DL/GEMM playground is an expense based on the portability offered by JAX like pure functions, and languages that can leverage an optimizing graph compiler using MLIR, with StableHLO for model, graph portability. So, Mojo + Python is in a unique position.
It's not at all a slight on Nim that Swift is better suited for a few things w.r.t C++ because Apple has unlimited resources to solve them. It is more a read on the ecosystem of indies because it is Apple. But these things have surprised me. I actually think people ranting about Nim lacking such & such vs Go or anything else are missing the point. Either one has to be ready to engineer a solution or go with what's best available (no pun intended), and make things work together. Nim can ingest as well as expose C APIs effortlessly.
That's my whole thing. Nim on its own can do a lot of cool and great things. But it doesn't need to do it all. I'll have to write on another day about how MummyX could be used for hybrid mobile apps using Turbo Native (from 37signals). Nim is the orchestrator on either side.