The notion that we need to all program in the top 10 popular programming languages seems dead with the advent of LLMs.
I program a lot in Nim including professionally and strongly prefer it over Rust or even Zig.
Primarily because I just really enjoy programming in Nim and getting things done I wouldn’t have otherwise or be capable of doing.
For example recently I needed to automate a GUI app. I tried the Python libraries but found they kinda sucked. Despite pulling in opencv they were slow at finding buttons in a screenshot. Then the one I tried also broke on hidpi displays.
Instead I got Claude to write me up a Nim library to find images in a screenshot. Then had Claude add SIMD to it.
It’s far faster than the python libraries, supports hidpi, and is far easier to install and use. I still use a small Python app as a server to take the screenshots but it’s a nice balance.
> I guess a lot of languages are kind of fungible. If you want a fast, cross platform, GC-based OOP language, the truth is, there are many choices.
It’s true, in many cases they are fungible. Though much less so for languages which compile to native code. LLMs do lower the barrier to switching.
Nim isn’t really a GC’ed OOP language though it supports some bits of that.
It’s really a systems language that can also run anywhere from an embedded device to a web server and as a JavaScript app.
The new default memory management is based on reference counting with or without a cycle collector. So it’s great for latency sensitive settings.
> The notion that we need to all program in the top 10 popular programming languages seems dead with the advent of LLMs.
To my mind, to the contrary :( LLMs get trained on corpora of existing texts, including source code. They become much better at massively used languages because of the plethora of training data, and struggle with more niche languages because of the dearth of good examples. It's a positive feedback loop for mainstream languages, because more stuff gets vibe-coded, or code-assisted when the AI does a better job at it. It's a negative feedback loop for niche languages because the opportunity cost of choosing them grows :(
That hasn’t been my experience with Nim so far. Both Claude 4 and GPT5 both one shot Nim code almost perfectly now. They even made a Nim JavaScript app for me.
On top of that I’ve been able to “vibe” code a couple of different libraries for Nim. The bigger limits with LLMs is still “deeper” and loosing track of what it’s doing.
It helps that Nim doesn’t have much unique syntax requirements or paradigms like say Rust lifetime annotations. Some of the rarer Nim idioms like `set[Enum]` being castable to a cint aren’t used.
But generally what you’d do in most C++ code works well in Nim, but with simpler syntax.
i had the same thought as you as i was reading GP comment but lately i've come across some videos on 'Interpretability' of llm output where they said llm store 'core ideas' in a abstract way and produce concrete output on the fly based on that core representation. This is very different from viewing llms are next token predictors which would imply what you said in your comment.
Using LLMs to build the libraries you need seems like a fantastic way to work with them, since they've probably been trained on code that does similar things.
> Nim isn’t really a GC’ed OOP language though it supports some bits of that.
I'm not sure about the OOP part, but last time I checked the standard library assumed the GC was enabled, so on that side I believe it's much closer to those languages than to C/C++/Rust/Zig
ARC's ref is similar to C++'s shared_ptr, or Rust's Rc - with that alone
it might still count as "GC'ed". But ARC also has ownership semantics,
and hooks for custom containers: https://nim-lang.org/docs/destructors.html
so I think it's fair to put it in the "system language" category.
A Nim object is a stack-allocated value type, without refcounting.
You can put that in a heap-allocated seq (pass-by-value with move
semantics), ref (refcounting), a custom container (you decide), or ptr
(unsafe, like C).
I’d say the majority of Nim’s stdlib can be used without ref (arc) types. The compiler only generates ARC code if you use ref types not when you import a module.
Yeah much of the basic stdlib only uses vector, string, and map types which are similar to C++ & Rust ones with single ownership and move semantics. Static arrays can be used with many basic functions like sort.
The JSON module in Nim’s stdlib does use ref ARC types. However neither C++ nor Rust provide a JSON module by default.
Actually, a fair bit of Nim’s stdlib can even be used without allocators! Unlike Rust’s #[no_std] for embedded which is just a pain.
Common, yes, although extremely common, that depends on the codebase and its goal. But they are not the default, and that what makes them system languages.
Not really, because they are not Automated Reference Counting, rather manual with explicit clone operations, in some scenarios.
Also contrary to systems where reference counting is part of the type system, and not library types, they aren't able to optimize counts away.
When this happens is as side effect of the compiler optimizing away inlined code, but not by pairing inc() with dec() operations that never leave scope.
>The notion that we need to all program in the top 10 popular programming languages seems dead with the advent of LLMs.
It was dead prior to this. A subset of programmers think it's hard to program in any other language other than the one or two they studied.
They are wrong. Most programming languages are very very similar. And learning one means you learned almost all. i learned new languages on the regular pre - llms and it required barely any effort.
Most company interviews are also language agnostic for this reason. Because languages are so trivial to learn once you "get" how to program.
> Most programming languages are very very similar.
For the most part, yes. I'd add the caveat of needing to differentiate significantly between imperative and functional programming, though. I've used Python, Java, C, C++, C#, PHP, and a TINY bit of Perl (Enough to know it's a terrible language -- seriously, why would anybody want to use a language that people refer to as "write-only" because it's so hard to read?), and Haskell just makes no damn sense to me. It seems its only use is to show off how Quicksort can be written in two lines with it, or to start fights over whatever the hell a Monad is.
Also, if you've only ever written in memory-safe languages like Python, Java, and C#, then switching to an unsafe language like C or C++ will probably result in writing a ton of memory leaks, buffer overflows, and segfaults.
Why are there hundreds of food recipes in the world? Shouldn't the most delicious dish just kill all the others? In the end there will be only one dish and we will all eat only that.
I program a lot in Nim including professionally and strongly prefer it over Rust or even Zig.
Primarily because I just really enjoy programming in Nim and getting things done I wouldn’t have otherwise or be capable of doing.
For example recently I needed to automate a GUI app. I tried the Python libraries but found they kinda sucked. Despite pulling in opencv they were slow at finding buttons in a screenshot. Then the one I tried also broke on hidpi displays.
Instead I got Claude to write me up a Nim library to find images in a screenshot. Then had Claude add SIMD to it.
It’s far faster than the python libraries, supports hidpi, and is far easier to install and use. I still use a small Python app as a server to take the screenshots but it’s a nice balance.
> I guess a lot of languages are kind of fungible. If you want a fast, cross platform, GC-based OOP language, the truth is, there are many choices.
It’s true, in many cases they are fungible. Though much less so for languages which compile to native code. LLMs do lower the barrier to switching.
Nim isn’t really a GC’ed OOP language though it supports some bits of that.
It’s really a systems language that can also run anywhere from an embedded device to a web server and as a JavaScript app.
The new default memory management is based on reference counting with or without a cycle collector. So it’s great for latency sensitive settings.