It makes me sad that neither Nim nor D didn't take off. Expressive language with native compilation and automatic memory handling is the way to go for me. C# and Java native AOT options are still somewhat limited, and the last thing one can say about Go is that it is expressive.
You may want to look into OCaml and Dart. Both are highly expressive, have automatic memory handling, native compilation and excellent performance.
I like D, but it's a bit of a mess at the moment with the DIP-1000 (Rust-inspired stuff for memory management) half-baked changes, the new experimental allocators (probably coming from Zig), it keeps breaking (on MacOS at least). With the very advanced metaprogramming, it also suffers from lack of good tooling, just like Nim... Nim was going to "solve" that a few years ago, but as far as I can see from the outside, nothing really "shipped" recently to improve the situation. Without good tooling, I am quite sure I am more productive even in Rust (and I am no expert on it), let alone OCaml (tooling is decent, and the language is just really powerful) and Dart (which has absolutely awesome tooling), for example.
I feel like Nim made me fall in love with programming again.
Nim fixes many of the issues I had with Python. First, I can now make games with Nim because it’s super fast and easily interfaces with all of the high performance OS and graphics APIs. Second, typos no longer crash in production because the compiler checks everything. If it complies it runs. Finally, refactors are easy, because the compiler practically guides you through them. The cross compiling story is great you can compile to JS on the front end. You can use pytorch and numpy from Nim. You can write CUDA kernels in Nim. It can do everything.
I feel like Nim, along with C#, is one of the few languages that just cannot be used without a great IDE.
It heavily encourages namespace pollution and `import *`, making it very hard to figure out what where a given function is coming from and hence what it does.
That’s very interesting actually. Can you call only specially wrapped libraries from Nim, or is any Python library importable? When you cross-compile to JS can you only use pure-Nim libraries or how does that work?
It's not a built-in Nim feature, and it'll only work with native backends (C/C++/ObjC). The project that makes it possible is https://github.com/yglukhov/nimpy
>typos no longer crash in production because the compiler checks everything.
Gentle correction: Python is typed now too and you can get the benefits of typing both in your IDE (via LSP) and before deploying to production (via mypy and the like). This happens both by type inference as well as explicit type annotations.
That's the dream. Reality is very different. Mypy presents numerous false negatives and false positives. Useful to screen for some bugs, but definitely far from giving guarantees.
Not to mention, if a library does not or does sloppily use type annotations, you would not get reliability even with a perfect type checker.
I'm sure you're right that there are situations where mypy or ty or LSP give false positives/negatives, but in my use of them over the last ~6 months I really haven't run into many of those situations, or at least none come to mind. Libraries without type annotations do reduce the effectiveness to just what can be inferred by the type checker.
you need to work on big project for these flaws to become a problem. Say, you have a huge code base, 100000's of lines that you didn't write. Then you want to refactor a method's name. Python can't give you any guarantee the refactoring is fully complete. Only a real typed language can do that.
I write 95% of my code in python, I love it, it's my go to language for many things. But for huge code base which I don't master, the lack of type system makes me more than nervous.
Sure but you can also write bugs in a perfectly typed compiled language. Short of formal verification the best we can do is try to minimise the possible surface for errors to occur. I'm of the opinion that language and tooling plays only a small part in writing robust software. What's more important is designing software using simple components that are small enough to be obviously correct.
I think languages that favor an "expressive" syntax, which favor using and building syntactic sugar and macros, suffer from a nicheness problem.
That is they are going to have to appeal to people who want that style of programming, and they have the additional hurdles of A) having more stuff one has to learn to use the language, B) dealing with a community of people who all want the magic from their previous language ecosystem imported into this new one, and C) the additional burden on libraries to come about which use these features.
Note: I have not used Nim, so please take the above with a lump of salt.
I've used nim a bit and am going to push back quite hard on this. The core of the language is really quite consise. No harder of a mental overload than say go, or python.
I'd also argue that high expressiveness actually allows you to avoid magic. The actual library implementations are rarely very scary. We're ahead of time compiled and type checked so it's not like some rails codebase where a clockwork goblin can just explode out of nowhere.
Macros in general are actually hugely anti-magical things because they let you push what normally be runtime checks into the compiler which not only means you get to fail fast but (if your language tooling is decent) means you actually get sane error messages instead of a traceback nested 1000 function calls deep or something.
I often wonder why some languages succeed while others falter. Why did Rust break through, for example, while so many other excellent languages didn't.
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. I'm not saying they are the same, but for 80% of the use cases they kind of are, and there are always good reasons to use established languages rather than new ones.
The ones that make it offer something very unique, not merely better than peers. So Rust, as a memory-safer non-GC language has a clear use case with little or no competition.
Nim doesn't have this luxury. I wish it well, I like the language and often contemplated learning it properly. But I fear the odds are against it.
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).
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.
>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.
Rust tooling, ecosystem and crates are much, much more mature. Many Nim libraries are unfinished, unsupported or abandoned. The language itself is pretty great, but you have to write most of the stuff from scratch.
In Nim it's very fast and ergonomic to write a MVP, but in Rust you have to think of the problem first.
I guess it's a double-sided edge: Rust is much worse for explorative programming compared to Nim, but that also forces people to build proper abstractions from the start. Which seems to directly feed into the quality of produced libraries.
I happen to prototype in python then move on to rust when things solidify... For those who don't know rust, its compiler is pretty slow. I mean, when you want to add a feature to an existing code base, each "run" you do to test the new feature imply relinking the whole project: that's very slow (or you have to split the project in sub project, but I'm lazy). In that situation, prototyping in python makes sense (at least to me :-)
I really feel for new languages that have to compete with Rust.
It’s probably easier than it’s ever been to create a high quality new language but to get as good as Rust has become just takes so much time and collective effort that it can be out of reach for most ecosystems/groups of builders. Getting the language features just right (and including novel stuff) is just the beginning.
Remember when Rust and Go were comparable? Feels like forever ago when they both just looked like “new systems programming languages” a we know how that turned out.
For example Zig is probably the most impressive new language, and it’s got a ton of awesome stuff but the chance that I’m going to adopt it over a language with often comparable performance that is ALSO much safer? Rounds to zero.
Maybe some day I’ll have the brain cells and skill to write code in zig and be confident I’m Not introducing a whole class of gnarly bugs, but it seems like I should just focus my limited brain power on writing high quality Rust code.
They were never intended for the same niches. Go is a Java/Python replacement. Rust is more of a C/subset of C++ replacement. They were compared mostly because they had usable versions released at approximately the same time, but you (correctly) don’t see those comparisons anymore.
Other WAY more qualified people already responded and elucidated on the initial origins of Rust (it used to have a garbage collector!), but I can at least add this:
The definition of "same niche" is doing a lot of heavy lifting.
There's a marked difference between what these tools became and the impression of them along the way and the axes along which they were compared in actuality. In the simple "I need to build a backend" conversation, Rust and Go were comparable long after Rust changed to a "real" systems language -- I'd go as far as to say people still compare them to this day (and Go probably wins that larger niche for many contextual reasons).
I think the point is partially reflected in your own statement -- there are many axes along which Go is not a Java replacement, and is not a Python replacement either. The definition of the "niche" vastly changes the answer.
For example, if you pick the right niche (e.g. HFT) Java meaningfully outperforms Go because high performance Java is... actually high performance -- those millions of man years into the compiler, runtime, etc produced progress. That said both of those languages get trounced by the FPGAs and custom hardware in the end.
I'm not convinced it was always wrong to compare Rust and Go, but the modern understanding of how different they are today is definitely better/I am glad they're more separated/more people know not to directly compare them.
Way back when Rust was first made known outside of Mozilla; it was pretty close to Go. While the intent was to be super low level, it didn’t really achieve those goals until years later, and kind of at the expense of parts of the original vision.
Yes, as you can see for what is possible to express with Pyright.
Just because Python is dynamic, doesn't mean it lacks the notion of a type system, or the whole set of concepts that Go has no way to express, like meta-classes, multiple inheritance, comprehensions (eager or lazy),....
Many folks going from Python to Go, would never done it if Python had a modern JIT on CPython, or the package management wasn't the way it is, hardly anything to do with the language itself.
>For example Zig is probably the most impressive new language, and it’s got a ton of awesome stuff but the chance that I’m going to adopt it over a language with often comparable performance that is ALSO much safer? Rounds to zero.
1) Rust, in practice, is "safer" than Zig but doesn't seem to be "much safer".
> Our Zig codebase had one leak and one undefined memory access. That was really surprising to me (in a good way). Our Zig codebase is large, complex, and uses tons of memory tricks for performance that could easily lead to unsafe behaviors. I thought we'd have a lot more issues, honestly. Also, the one leak found was during calling a 3rd party C API (so Zig couldn't detect it). So this is a huge success.
Take that as you will. And what Ghostty does probably requires a decent chunk of "unsafe" that would likely hide a bug anyway.
To me, the tradeoff of a demonstrably small number of bugs in a system software language in return for the demonstrably faster developer velocity (Zig compiles WAY faster than Rust, Zig wraps C/C++ libraries way easier than Rust, Zig cross compiles way more easily, etc.) is a decent tradeoff for my use cases.
For me, programming is about corralling motivation more than anything else. Rust saps my motivation is ways that Zig does not.
I love what the Oxide folks are doing. Having someone pwn your big server because of a memory bug? Yeah, I'd reach for Rust in their use cases. Or, if I'm handling credit cards, I'll have a very different set of tradeoffs that swing against Zig. (Although, in that case, I'll probably reach for a GC language in that case so that I don't have to think about memory management at all.)
2) Rust is to C++ like Zig is to C.
Zig is simply a much smaller language than Rust. I use Zig because my brain isn't big enough for either C++ or Rust.
I'm not a 10x programmer, but I still want to get stuff done. Zig and C enable me to do that without bending my brain.
> For me, programming is about corralling motivation more than anything else. Rust saps my motivation is ways that Zig does not.
Yes, agree with you a lot! Maybe our brains are just wired differently, for me, no other language (until now) gives me as much motivation as Rust, as it's type system and docs make me feel really good.
> Zig is simply a much smaller language than Rust. I use Zig because my brain isn't big enough for either C++ or Rust.
Disclaimer: haven't really tried Zig yet. IMO you don't need to keep the whole of Rust in your brain to use it, I usually can just focus on the business logic as if I make a stupid mistake, the compiler will catch it. That (and the type system) is what makes me more efficient with it than other langs. I also stay clear of lifetimes unless I really need them (which is almost never for application code). An extreme example of the opposite is C, where I need to take care about anything I do as it will just accept anything (e.g. auto casting types) so I need to be vigilant about everything.
All of that said, there are patterns that will just be harder to reason about in Rust, mostly with self-referential things, and if you area already used to using them a lot, this can be a hassle. If you're used to smaller data structures and data-oriented programming, it will be a lot easier.
This is not trying to convince you or anyone else, just showing a different perspective. If you feel better with Zig, use it! Everyone has their own experience.
> All of that said, there are patterns that will just be harder to reason about in Rust, mostly with self-referential things, and if you area already used to using them a lot, this can be a hassle. If you're used to smaller data structures and data-oriented programming, it will be a lot easier.
Also an underrated chance to be forced to learn about Arenas, most of the time.
Yeah, not everyone is mitchellh -- I'd argue that his intuition was right (expecting to find more issues), there's a reason we don't all write C.
That said, it's great to hear that others are having success with Zig and aren't writing very many bugs.
> To me, the tradeoff of a demonstrably small number of bugs in a system software language in return for the demonstrably faster developer velocity (Zig compiles WAY faster than Rust, Zig wraps C/C++ libraries way easier than Rust, Zig cross compiles way more easily, etc.) is a decent tradeoff for my use cases.
Reasonable points! This is one of the reasons I have on my list to consider Zig at all (that and wanting to write more C), it seems people that like it are wonderfully productive in it.
I really like a lot of the design decisions and watch the streams than Andrew and Loris, Tigerbeetle folks and others do to see the decisions they make. Their managed IO approach is certainly interesting and quite powerful.
Dislike some small petty syntax things (whyCamelCaseFunctions()!?), but that's a me thing.
> For me, programming is about corralling motivation more than anything else. Rust saps my motivation is ways that Zig does not.
Agree with this, anecdotally.
> I love what the Oxide folks are doing. Having someone pwn your big server because of a memory bug? Yeah, I'd reach for Rust in their use cases. Or, if I'm handling credit cards, I'll have a very different set of tradeoffs that swing against Zig. (Although, in that case, I'll probably reach for a GC language in that case so that I don't have to think about memory management at all.)
Yup, Typescript works for me here, and usually the hard parts are offloaded to an external service anyway (e.g. Stripe)
> Zig is simply a much smaller language than Rust. I use Zig because my brain isn't big enough for either C++ or Rust.
>
> I'm not a 10x programmer, but I still want to get stuff done. Zig and C enable me to do that without bending my brain.
I wouldn't put Rust and C++ in the same league there as far as brain size requirements, but point taken!
> Yeah, not everyone is mitchellh -- I'd argue that his intuition was right (expecting to find more issues), there's a reason we don't all write C.
I'd argue this is also down to the debug memory allocators in Zig which run a bunch of checks for things like use-after-free. Again, one of the nice things about Zig is that debug mode isn't dramatically slower than release so you're not inclined to turn it off too soon.
However, one thing that does shock me is that no "reference to stack allocated thing escapes" errors existed. Zig does not help you very much on this front, and I'm stunned that none existed.
> I'd argue this is also down to the debug memory allocators in Zig which run a bunch of checks for things like use-after-free. Again, one of the nice things about Zig is that debug mode isn't dramatically slower than release so you're not inclined to turn it off too soon.
Ah another good point -- also excited for what opens up with regards to this approach with managed/explicit I/O. Pretty obvious that permutation testing of async behavior gets unlocked which is nice. The equivalent in Rust would be loom.
> However, one thing that does shock me is that no "reference to stack allocated thing escapes" errors existed. Zig does not help you very much on this front, and I'm stunned that none existed.
TIL -- is everyone just bolting on asan here and sticking to the clang backend for now?
>a language with often comparable performance that is ALSO much safer
There are domains where performance is critical and safety isn't so important (e.g. video games). Zig has an advantage in such domains because of the pervasive support for passing around allocators in the standard library (avoiding hidden allocations, and allowing efficient memory reuse via block allocators), while in the Rust stdlib custom allocators are relatively cumbersome to use (and not easy to prove safe to the compiler).
Agreed, I really like Zig's explicit allocation (and to be fair, lots of people from Rust like it too[0], it's just such an insane lift that who knows when it will stabilize)
The new "managed" async strategy (I was previously mistaken thinking it was the same as sans-io) is also really intriguing IMO, and feels like a fantastic balance (people in Rust are doing this too, but for the unrelated reason of trying to support various async runtimes).
> Maybe some day I’ll have the brain cells and skill to write code in zig and be confident I’m Not introducing a whole class of gnarly bugs, but it seems like I should just focus my limited brain power on writing high
Have you tried using an LLM with Zig? When the training sets are on different language versions and there are breaking changes you may find it challenging.
I actually enjoyed zig because it prevented me from using LLMs to code in this way
I use LLMs almost daily, and they certainly don't "solve" the problem of finding bugs, not even in popular languages like TypeScript. They do help a lot, yes, but they haven't solved it completely.
My personal experience has been different. We recently onboarded a whole team of Devs on a language none of us mastered and it's been running in prod with only a couple bugs so far in 6 months, much lower than our average with our normal stack that everyone masters
> I often wonder why some languages succeed while others falter.
IME language success has very little to do with syntax, and much more to do with stdlib, tooling, library availability, coverage on StackOverflow and all the other things that make solving problems simple.
I vaguely remember a talk given by the creator of ELM called "The Economics of Programming Languages". It's actually really expensive to make a good programming language that's widely used.
Forget about syntax or semantics or unique features or whatever. Having money and resources are the most important factor for a successful language.
Oh boy, I always had this knack for seeing/testing multiple langauges and when I had first discovered nim, I used to watch some nim youtube related content and I remember someone in nim community pointed out about this same video from the creator of elm that you also mention.
So, I think that I had watched the video and honestly, I will watch it now once again since I don't remember it clearly but If I remember, I really liked it.
The volume of work required to get a language going practically requires full-time headcount. Language design/compiler, community website, documentation, CI, libraries (json, datetime, regex, database connectors, web server, etc), treesitter IDE plugins. A lot of different required hats.
Sure, you can scrape by with a rag tag group of volunteers, but to ever get to mass adoption requires a lot of work and dedicated resourcing. Zig has been in development for how long now, and that is with the designer now working on it full time.
Yes. Writing a language in your free time means juggling work on the side. Or you can be at Google and get paid to write Go for your job, and get free marketing from it. Even Rust had the backing of Mozilla. Until your "pet" language reaches critical mass that you can sustain yourself and quit your day job, you're fighting the giants.
I almost always choose Go over Rust when they are similarly suited to something. I only use Rust when Go's safety isn't sufficient. Go is a joy to use, Rust rarely is (in my experience).
I wouldn't say either of them have won. I'd say both are amazing tools, too. We're spoiled for choices these days.
Rust was backed by Mozilla at first and now it's backed by Amazon, Google, Microsoft and others...
Go and Rust don't compete, Go has a GC, they're in fundamentally different domains. Google also uses Rust, among other languages (C++, Java, Python, Go, JS, etc...).
Sorry, I guess I’m biaised but I see a lot of Rust-based projects on HN and not many in Go, and in the latest StackOverflow survey Rust is way ahead of Go as "admired language" and a language that people want to work with.
Dart is really successful. Just look at the latest release that just came out. It’s a really great language and now runs about as fast as Go while looking as good as Kotlin.
Concur on the [special case] of rust: It's in a domain that only has a handful of competitors (For its core competencies of system performing, high-performance programming, and embedded). It has learned from , and made improvements on them.
They also backed down from the initial claim of full Python compatibility. Which was the entire appeal of the venture. If you cannot seamlessly drop into the Python ecosystem, it is just another scripting language with better architecture to enable faster code.
Mojo is not a scripting language in the usual sense. It is a system programming language more akin to Rust. Their aim is to have better ergonomics than Rust.
I really wanted to love nim. I wrote a bunch of tools in it, had fun, and then ultimately rewrote them all in rust. The library situation in nim is just unfortunate, and I say that as someone who uses elixir. That, and the cross compiling took far more effort than getting the same code finished on rust, which was little more than "use cross"
I keep hoping nim will get better, because it's a beautiful language that produces absolutely tiny, efficient binaries
Nim is a programming language for an expert programmer. The ecosystem is very small and for everything a little bit more specialized you need to make a library yourself.
That's plus for individuals but minus for languages.
Personal anecdote: I was exactly there a decade ago when I was working on Chrono, now one of best-known date and time libraries in Rust. Since I was simply my own, my design was not as good as it could have been. Of course it is still much better to have a suboptimal Chrono, but I can't deny that it remains and probably will remain suboptimal due to my design a decade ago.
This usually ends up in a situation where most of the significant libraries for the language are abandoned GitHub repos with 13 stars and no documentation ("You just have to read the code!!1!").
This. I really wanted to like Nim. I tried to learn it, but having never been a programmer before (but years of Linux admin, puppet, terraform and scripting) I found it extremely tough, and a lot of documentation is out of date and the there aren't many good examples to follow. Switched to Go and have built lots and lots of stuff in go.
Please, file bugs or complain on the official matrix room. The community tries its best to keep up the official documentation in sync with the changes.
Whenever I’m missing a library I’m usually just 5 mins away from successfully using a C library (or any library with a C API). In my years doing data analysis, signal processing, and just writing plain servers I’ve never once gotten stuck because of a missing library.
Exactly, I had tried nim but I felt the same issue.
I mean, personally I really like golang. Its actually gotten an ecosystem that functions while being able to cross compile and actually being easy enough to learn unlike rust.
I also sometimes exclusively just use typescript/python just for their ecosystem as a junior programmer. For me ecosystem matters a lot and this was a reason why I wish that more languages can create more libraries which can work.
Like the article pointed, nim is really solid language. But I'd like to see more libraries being made for it.
So, there I was in 2016. It had been 13 years since I had last entertained the desire to learn a new programming language (I had landed on Python, back then). The serious contenders were Go, Nim, and Rust. I landed on Nim back then, thinking to myself: Man, this language really has a future. I did my next side project in Nim, and loved it like I've loved no other language over the course of my (as of now, in 2025) 28 years of programming. But no actual job ever materialized to make me into a professional Nim programmer that would actually pay the bills. I stuck it out with Python, with growing discontentment. I took a Perl job in 2018, which lasted until 2022, which I never should have taken in the first place. I was relatively free in my choice of language from that point forward, and decided to switch from Python to Lua after a short period of disorientation where I kind of liked Haxe. Right now, I'm learning Rust, crying tears over that future for Nim that never materialized.
Had almost the same situation to a tee around the same time (~2014). Decided between Rust, Nim, D and Go. Went with Rust then and quickly felt it had been the right choice since it really helped me improving my skills and got me interested in programming again after a few years away from it. Rust community was way smaller and more approachable, the language felt exciting and really delivered on its promises.
Then around 2019 Nim started to gain momentum (preparing for 1.0 release) and when I looked into it a bit deeper it became evident that for most of the code I usually write for myself Nim is just a more pragmatic choice than Rust. It gets me there faster.
Zero job perspectives both times, scratched my own itch twice though.
Glad I haven't gone with Go. Nim is not a perfect overlap with Rust, but it definitely covers everything Go can do and more and is a better design in my opinion.
Honestly, we can all still correct it if we really want to. Nothing is too late in my opinion, but the question that I wish to ask is, is it worth it?
I mean, compared to zig which is starting to have a lot of hype and libraries / help, lets say that we now wish for nim to have this, then are the feature differences b/w zig and nim worth the revival of nim in that sense? (Pardon me if this doesn't make sense)
I fell in love with Nim a couple of years ago, but feel like Zig gaining popularity has really pushed Nim out of the limelight in terms of developer adoption.
Nim has been on my radar for a while, but I've never really dug into it. I have actually written some small projects in Zig though. Are there things you think Nim does better than Zig?
I think Nim and Zig target very different audiences and have very different goals. Nim is about being a big, powerful language with lots of features, so that you have the freedom to use it the way you want, e.g. there is OOP with methods, but it's completely optional. Zig is explicitly against that, even on the homepage you can see: "No hidden control flow. No hidden memory allocations. No preprocessor, no macros.". While memory management in Nim by default is completely automatic, and templates/macros are quite common.
It makes much more sense to compare Nim to, say, Swift, D, or other modern compiled languages with lots of syntax sugar.
What a low effort article. I have done some programming in Nim. It’s a nice language but I felt frustrated whenever I wanted to do something I knew I could do in python but that didn’t work in Nim. I just missed some of the syntactic sugar of python, that being said I would love to get back into Nim again.
You know what, I mostly do python, but then had to get quite high performance on some lib. Converting to Nim and importing with nimpy has been a blast. The result is just one more python module, colleagues don't get frightened when they see the code, it's just seamless and nifty. I much prefer it to Cython.
If I remember correctly it was when working with collections but I can’t remember a concrete example though. Their std library is by no means bad it is just different enough from python to hurt my productivity. My initial motivation for chosing Nim was because I was doing an algorithm course at the time and I wanted to archive fastest runtimes in shortest amount of code
It’s growing steadily but I do qualitatively feel like the ecosystem has lost a bit of steam over the past year. Excited for the ongoing Nim tool chain work though.
Yes, you can use the Zig compiler as a C backend for Nim by setting `--cc:zig` in your Nim compiler flags, which provides better cross-compilation capabilities than traditional C compilers.
Yes, I tried it recently for easy cross-compilation. You can use basically any C/C++ compiler, even TinyCC works (in most scenarios) if you want an extremely fast edit/compile/test cycle.
From a promotional marketing perspective, that webpage misses quite a few basics, like linking to the Nim site [0] and explaining what it actually does:
Nim is a statically typed programming language that compiles to native dependency-free executables in C, C++ or JavaScript.
IMHO it is a good choice. You shouldn't have variables around that are different only on one cased character, or because one is snake_case and the other is camelCase. It also avoids the contamination of your code when using for example a C library in snake_case while your library uses camelCase. And finally, you can refactor a library in snake_case to camelCase without breaking dependent code.
The first character is actually not considered for case insensitivity, although it was in the past. :) And case insensitivity itself comes to Nim from Pascal.
The underscore thing gets me more than the case insensitivity, FWIW. We have tools for case insensitive greps, but underscore normalizing ones are rare.
“Has safety features in place”? I’m sorry, not gonna cut it.
I mean, Nim looks cool, but I’m not sure what it does that is substantially new. Niceties are generally not enough to foster adoption - something real has to be on the table that meaningfully opens up new avenues, unlocks new paths, enables new use cases.
I'm sure that's nice, but it's not a game changer. You can do metaprogramming in other languages as well, and maybe those languages get it not quire as right as Nim, but it's not enough to tip the scales.
Yes, compile-time execution in Nim is very natural, if you mark a variable "const" or use some other ways, you can run almost all pure-Nim code at compile-time without having to modify it.
I could never understand why people care this much about significant whitespace of all things. This seems like such a non-issue, it should be a minor annoyance at worst. Then again my favorite language is Lisp, so maybe I'm just too much beyond caring about syntax. The only annoying thing about significant whitespace is having to escape a new line sometimes.
But significant whitespace has always made sense to me. You are going to indent your code anyway, so you might as well give the indentation some meaning. I write Python, JavaScript and Lua most of the time, and I never waste any thought on whitespace VS braces VS keyword delimiters.
I can count multiple reasons why someone might dislike significant whitespace. The most evident is that whitespace is... not evident at all! By definition, it's a transparent character: it's extremely difficult to directly count spaces; they can be indirectly counted by comparison with text in the surrounding area. The same principle why we add commas or apostrophes or spaces every 3 digits in big numbers.
As of the "you're going to indent your code anyway" claim, this seems to completely ignore one-liners, either embedded in other documents (onClick=...) or fed to the shell as a quick way to get some work done without spawning new tools.
> You are going to indent your code anyway, so you might as well give the indentation some meaning.
Autoformatters came and fixed that problem. Nobody (except python, haskell and nim coders probably) wastes time indenting code anymore, you save and your code is indented. Nowadays, code that relies on whitespace and has no ending delimiters (like nim and python) gets awkward because the formatters have less information to go on. If your rust or typescript code formats to bad indent or none at all, you have an error.
It's harder to tell where code blocks end just by looking
2, I sometimes want to fuck up the indentation on purpose, if I'm just quickly pasting some code to test if it even works or to mark it as "look at it in 5 minutes from now". Also I can mix spaces and tabs
quick edits it notepad/vim/whatever become painful
also converting tabs to spaces or vice-versa is tiring. A language shouldn't force me to a particular code style
It’s subjective, but this is also why I haven’t tried Nim or Crystal. If you like brackets, I’d say try Swift if you want to stay in the natively compiled + GC space.
I've really never understood where this aesthetic preference comes from.
Back when most of my code was in C or C++ (or Java), I was told all the time, sure you can omit these braces for a single-statement block, but you shouldn't, you'll regret it later. You can leave all the code unindented or irregularly indented, it won't matter to the compiler, but you'll appreciate lining it up in the long run. And all that advice was correct; I was better off in the long run, and I saw others come to regret it all the time. But then, over time, I started to wonder why I had to scan past all these diagonal lines of close braces as I read the code. And I cursed that these languages made it too difficult to pull out the inner parts into separate functions, disentangle setup and teardown from the main loop etc. But I also cursed that after putting in the effort (even if was just "using a proper text editor") to make things line up beautifully and in agreement with the logical structure, I still had to take up vertical space with these redundant markers of the logical structure.
Python was my first language using significant whitespace, and it was a breath of fresh air. That was a bit over 20 years ago, I think. I've learned several other programming languages since then, but I never "looked back" in any meaningful way.
Every time I copy paste something in python I have to check the whitespace. Often there's a problem that needs fixing, like the first line indented differently, or everything is off. Sometimes I'm not paying perfect attention and get hard to catch bugs.
I'm now certain that significant whitespace is simply wrong.
Significant whitespace pushes a tooling problem (correct indentation) into the human domain. It might have made sense before autoformatters that run on save, but I agree with you that in today's languages, it's a net negative.
As far as I'm aware, none of the new languages that have seen success in the last ten years (Go, Rust, Swift, Dart, Kotlin) rely on the author to format code correctly - instead, they do it for you. And that's good! That's one less thing the programmer has to worry about!
> Significant whitespace pushes a tooling problem (correct indentation) into the human domain. It might have made sense before autoformatters that run on save, but I agree with you that in today's languages, it's a net negative.
Sorry, I don't follow. There's nothing preventing a tool from re-indenting code when it's pasted (i.e.: considering indentation within the pasted text relative to its first line, and then applying an indentation offset according to where it's pasted), and many already do. It's the same kind of logic that's used to auto-format code in braced languages; arguably simpler unless it's also validating the existing indentation of the pasted text.
And actually, who even is relying on "autoformatters that run on save"? I want the code to look right as I'm writing it, not after. The tools you describe are, to me, about maintaining project standards when multiple people are involved, but fundamentally each person is still making the code look locally, personally right before saving (or committing, since these things are also often done with pre-commit hooks). I can't imagine just typing out whatever slop is syntactically correct and waiting to save the file to fix it. Not when I have a proper text editor that facilitates typing it out the way I want it, taking advantage of awareness of the language syntax.
> none of the new languages that have seen success in the last ten years (Go, Rust, Swift, Dart, Kotlin) rely on the author to format code correctly - instead, they do it for you.
Languages do not and cannot format code. Text editors (including the ones built into IDEs) do. If I type a } and the text changes position, it's not the programming language that did this.
And this is also not better in braced languages. Just as I can input a } on a new line in Vim in a braced language and have it dedent, if I want to write more code in Python that's outside the block, I just press the backspace key and it removes an entire level of indentation. And then I start typing that code, and I don't have to input a newline because I'm already on the line where I want the code to be, because I'm not expected to have a } on a separate line from everything else.
> Sorry, I don't follow. There's nothing preventing a tool from re-indenting code when it's pasted (i.e.: considering indentation within the pasted text relative to its first line, and then applying an indentation offset according to where it's pasted), and many already do. It's the same kind of logic that's used to auto-format code in braced languages; arguably simpler unless it's also validating the existing indentation of the pasted text.
I have not had this work reliably for me - my relatively stock VSCode does not indent the pasted code correctly - but I will freely admit that it could, and that this is a point in favour of good tooling.
> And actually, who even is relying on "autoformatters that run on save"? I want the code to look right as I'm writing it, not after. The tools you describe are, to me, about maintaining project standards when multiple people are involved, but fundamentally each person is still making the code look locally, personally right before saving (or committing, since these things are also often done with pre-commit hooks). I can't imagine just typing out whatever slop is syntactically correct and waiting to save the file to fix it. Not when I have a proper text editor that facilitates typing it out the way I want it, taking advantage of awareness of the language syntax.
Most people who write code in these languages rely on them! Format-on-save is one of the first things one sets up in an ecosystem with high-quality formatters. You can write code that is sloppily formatted but conveys your intent, then save and have it auto-format. It completely reformats formatting as a concern. As they say in Go land: "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."
> Languages do not and cannot format code. Text editors (including the ones built into IDEs) do. If I type a } and the text changes position, it's not the programming language that did this.
These languages ship with first-class robust and performant formatters that encode the language's preferred style; much effort has gone into developing these formatters [0]. For all intents and purposes, they are part of the language, and users of these languages will be expected to use them.
> And this is also not better in braced languages. Just as I can input a } on a new line in Vim in a braced language and have it dedent, if I want to write more code in Python that's outside the block, I just press the backspace key and it removes an entire level of indentation. And then I start typing that code, and I don't have to input a newline because I'm already on the line where I want the code to be, because I'm not expected to have a } on a separate line from everything else.
I just don't think about it. I write my code in whatever way is easiest to type - including letting the editor auto-insert closing braces - and then hit save to format.
In general, you are freed from formatting as a matter of concern. It's just not something you have to think about, and that's liberating in its own way; it makes bashing some code out, or pasting some code in, trivial.
I've been certain that copy & pasting code is simply wrong for a long time, but if the ease of doing this is your yardstick for language design quality, then you are simply right.
Yes, optimize for the thing you do once in a great while over having to read/type redundant braces constantly. Wouldn’t want to have to pay attention and use the tab key! ;-)
Hello fellow programmer from the middle ages; we discovered long ago that significant whitespace is a dead end, the fact that it's popular with the wannabes changes nothing.
The main reason I never got into Nim is that I seem to recall it depending on mingw and that frankly always sets a language into a second-class category for me. Maybe now it’s different, I don’t know.
Nim is nice but I can't really find a use for it. Maybe it's because I started out on dynamic languages (Ruby and R) where I got used to writing in a dynamic language and then rewriting bottlenecks in C++.
Nim is in the awkward middle area where it's got a GC so it'll never replace C/C++ but it also isn't as productive as something like Ruby.
It makes me sad that neither Nim nor D didn't take off. Expressive language with native compilation and automatic memory handling is the way to go for me. C# and Java native AOT options are still somewhat limited, and the last thing one can say about Go is that it is expressive.
You may want to look into OCaml and Dart. Both are highly expressive, have automatic memory handling, native compilation and excellent performance.
I like D, but it's a bit of a mess at the moment with the DIP-1000 (Rust-inspired stuff for memory management) half-baked changes, the new experimental allocators (probably coming from Zig), it keeps breaking (on MacOS at least). With the very advanced metaprogramming, it also suffers from lack of good tooling, just like Nim... Nim was going to "solve" that a few years ago, but as far as I can see from the outside, nothing really "shipped" recently to improve the situation. Without good tooling, I am quite sure I am more productive even in Rust (and I am no expert on it), let alone OCaml (tooling is decent, and the language is just really powerful) and Dart (which has absolutely awesome tooling), for example.
I feel like Nim made me fall in love with programming again.
Nim fixes many of the issues I had with Python. First, I can now make games with Nim because it’s super fast and easily interfaces with all of the high performance OS and graphics APIs. Second, typos no longer crash in production because the compiler checks everything. If it complies it runs. Finally, refactors are easy, because the compiler practically guides you through them. The cross compiling story is great you can compile to JS on the front end. You can use pytorch and numpy from Nim. You can write CUDA kernels in Nim. It can do everything.
See: https://www.reddit.com/r/RedditEng/comments/yvbt4h/why_i_enj...
I feel like Nim, along with C#, is one of the few languages that just cannot be used without a great IDE.
It heavily encourages namespace pollution and `import *`, making it very hard to figure out what where a given function is coming from and hence what it does.
That’s very interesting actually. Can you call only specially wrapped libraries from Nim, or is any Python library importable? When you cross-compile to JS can you only use pure-Nim libraries or how does that work?
It's not a built-in Nim feature, and it'll only work with native backends (C/C++/ObjC). The project that makes it possible is https://github.com/yglukhov/nimpy
>typos no longer crash in production because the compiler checks everything.
Gentle correction: Python is typed now too and you can get the benefits of typing both in your IDE (via LSP) and before deploying to production (via mypy and the like). This happens both by type inference as well as explicit type annotations.
That's the dream. Reality is very different. Mypy presents numerous false negatives and false positives. Useful to screen for some bugs, but definitely far from giving guarantees.
Not to mention, if a library does not or does sloppily use type annotations, you would not get reliability even with a perfect type checker.
I'm sure you're right that there are situations where mypy or ty or LSP give false positives/negatives, but in my use of them over the last ~6 months I really haven't run into many of those situations, or at least none come to mind. Libraries without type annotations do reduce the effectiveness to just what can be inferred by the type checker.
you need to work on big project for these flaws to become a problem. Say, you have a huge code base, 100000's of lines that you didn't write. Then you want to refactor a method's name. Python can't give you any guarantee the refactoring is fully complete. Only a real typed language can do that.
I write 95% of my code in python, I love it, it's my go to language for many things. But for huge code base which I don't master, the lack of type system makes me more than nervous.
Sure but you can also write bugs in a perfectly typed compiled language. Short of formal verification the best we can do is try to minimise the possible surface for errors to occur. I'm of the opinion that language and tooling plays only a small part in writing robust software. What's more important is designing software using simple components that are small enough to be obviously correct.
"Is typed now" is false.
"Can be typed now" is somewhat correct.
"Can be partially typed now" is actually correct.
The fact that you have to run a separate tool just to check typing is a joke.
True but IME languages that are historically dynamically typed have a rough time truly converting to static types.
Php even seems to have decent static types these days, but do my coworkers use them? Hell no
Somehow "gentle correction" sounds more aggressive (passive aggressive) than just saying correction.
It's patronizing.
> Gentle correction: Python is typed now too
No it's not and you should lose your union card for lying like this.
Take a deep breath
I think languages that favor an "expressive" syntax, which favor using and building syntactic sugar and macros, suffer from a nicheness problem.
That is they are going to have to appeal to people who want that style of programming, and they have the additional hurdles of A) having more stuff one has to learn to use the language, B) dealing with a community of people who all want the magic from their previous language ecosystem imported into this new one, and C) the additional burden on libraries to come about which use these features.
Note: I have not used Nim, so please take the above with a lump of salt.
I've used nim a bit and am going to push back quite hard on this. The core of the language is really quite consise. No harder of a mental overload than say go, or python.
I'd also argue that high expressiveness actually allows you to avoid magic. The actual library implementations are rarely very scary. We're ahead of time compiled and type checked so it's not like some rails codebase where a clockwork goblin can just explode out of nowhere.
Thats good feedback, thank you.
Macros in general are actually hugely anti-magical things because they let you push what normally be runtime checks into the compiler which not only means you get to fail fast but (if your language tooling is decent) means you actually get sane error messages instead of a traceback nested 1000 function calls deep or something.
I often wonder why some languages succeed while others falter. Why did Rust break through, for example, while so many other excellent languages didn't.
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. I'm not saying they are the same, but for 80% of the use cases they kind of are, and there are always good reasons to use established languages rather than new ones.
The ones that make it offer something very unique, not merely better than peers. So Rust, as a memory-safer non-GC language has a clear use case with little or no competition.
Nim doesn't have this luxury. I wish it well, I like the language and often contemplated learning it properly. But I fear the odds are against it.
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.
https://www.youtube.com/watch?v=fGKNUvivvnc&t=2748s
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
It’s more that Nim2 moved from a GC to ARC/ORC, scope based automatic reference counting (ARC) with an optional cycle collector (ORC).
C++, Swift, and even Rust rely on reference counting quite a bit.
As long as it's effectively required by default I would place it in a category more similar to GCed languages than system languages like C++ and Rust.
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.
In Rust/C++ it is just one of the tools. Not required thing.
Neither is it required in Nim.
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).
Arc’s are extremely common in Rust and C++ codebases.
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.
>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.
If those 10 languages were good, why there are 10 of them? Shouldn't they kill each other? In the end there will be only one.
It’s like human language: your second one is hard, your fifth one is easy.
Rust tooling, ecosystem and crates are much, much more mature. Many Nim libraries are unfinished, unsupported or abandoned. The language itself is pretty great, but you have to write most of the stuff from scratch.
In Nim it's very fast and ergonomic to write a MVP, but in Rust you have to think of the problem first.
I guess it's a double-sided edge: Rust is much worse for explorative programming compared to Nim, but that also forces people to build proper abstractions from the start. Which seems to directly feed into the quality of produced libraries.
Just a hunch, not something I've thought through.
I happen to prototype in python then move on to rust when things solidify... For those who don't know rust, its compiler is pretty slow. I mean, when you want to add a feature to an existing code base, each "run" you do to test the new feature imply relinking the whole project: that's very slow (or you have to split the project in sub project, but I'm lazy). In that situation, prototyping in python makes sense (at least to me :-)
I really feel for new languages that have to compete with Rust.
It’s probably easier than it’s ever been to create a high quality new language but to get as good as Rust has become just takes so much time and collective effort that it can be out of reach for most ecosystems/groups of builders. Getting the language features just right (and including novel stuff) is just the beginning.
Remember when Rust and Go were comparable? Feels like forever ago when they both just looked like “new systems programming languages” a we know how that turned out.
For example Zig is probably the most impressive new language, and it’s got a ton of awesome stuff but the chance that I’m going to adopt it over a language with often comparable performance that is ALSO much safer? Rounds to zero.
Maybe some day I’ll have the brain cells and skill to write code in zig and be confident I’m Not introducing a whole class of gnarly bugs, but it seems like I should just focus my limited brain power on writing high quality Rust code.
>but it seems like I should just focus my limited brain power on writing high quality Rust code.
You're running out of brain for rust?
> Remember when Rust and Go were comparable?
They were never intended for the same niches. Go is a Java/Python replacement. Rust is more of a C/subset of C++ replacement. They were compared mostly because they had usable versions released at approximately the same time, but you (correctly) don’t see those comparisons anymore.
Other WAY more qualified people already responded and elucidated on the initial origins of Rust (it used to have a garbage collector!), but I can at least add this:
The definition of "same niche" is doing a lot of heavy lifting.
There's a marked difference between what these tools became and the impression of them along the way and the axes along which they were compared in actuality. In the simple "I need to build a backend" conversation, Rust and Go were comparable long after Rust changed to a "real" systems language -- I'd go as far as to say people still compare them to this day (and Go probably wins that larger niche for many contextual reasons).
I think the point is partially reflected in your own statement -- there are many axes along which Go is not a Java replacement, and is not a Python replacement either. The definition of the "niche" vastly changes the answer.
For example, if you pick the right niche (e.g. HFT) Java meaningfully outperforms Go because high performance Java is... actually high performance -- those millions of man years into the compiler, runtime, etc produced progress. That said both of those languages get trounced by the FPGAs and custom hardware in the end.
I'm not convinced it was always wrong to compare Rust and Go, but the modern understanding of how different they are today is definitely better/I am glad they're more separated/more people know not to directly compare them.
Way back when Rust was first made known outside of Mozilla; it was pretty close to Go. While the intent was to be super low level, it didn’t really achieve those goals until years later, and kind of at the expense of parts of the original vision.
Go is hardly a replacement with its weaker type system.
A weaker type system than Python?
Yes, as you can see for what is possible to express with Pyright.
Just because Python is dynamic, doesn't mean it lacks the notion of a type system, or the whole set of concepts that Go has no way to express, like meta-classes, multiple inheritance, comprehensions (eager or lazy),....
Many folks going from Python to Go, would never done it if Python had a modern JIT on CPython, or the package management wasn't the way it is, hardly anything to do with the language itself.
>For example Zig is probably the most impressive new language, and it’s got a ton of awesome stuff but the chance that I’m going to adopt it over a language with often comparable performance that is ALSO much safer? Rounds to zero.
1) Rust, in practice, is "safer" than Zig but doesn't seem to be "much safer".
See: https://mitchellh.com/writing/ghostty-gtk-rewrite
> Our Zig codebase had one leak and one undefined memory access. That was really surprising to me (in a good way). Our Zig codebase is large, complex, and uses tons of memory tricks for performance that could easily lead to unsafe behaviors. I thought we'd have a lot more issues, honestly. Also, the one leak found was during calling a 3rd party C API (so Zig couldn't detect it). So this is a huge success.
Take that as you will. And what Ghostty does probably requires a decent chunk of "unsafe" that would likely hide a bug anyway.
To me, the tradeoff of a demonstrably small number of bugs in a system software language in return for the demonstrably faster developer velocity (Zig compiles WAY faster than Rust, Zig wraps C/C++ libraries way easier than Rust, Zig cross compiles way more easily, etc.) is a decent tradeoff for my use cases.
For me, programming is about corralling motivation more than anything else. Rust saps my motivation is ways that Zig does not.
I love what the Oxide folks are doing. Having someone pwn your big server because of a memory bug? Yeah, I'd reach for Rust in their use cases. Or, if I'm handling credit cards, I'll have a very different set of tradeoffs that swing against Zig. (Although, in that case, I'll probably reach for a GC language in that case so that I don't have to think about memory management at all.)
2) Rust is to C++ like Zig is to C.
Zig is simply a much smaller language than Rust. I use Zig because my brain isn't big enough for either C++ or Rust.
I'm not a 10x programmer, but I still want to get stuff done. Zig and C enable me to do that without bending my brain.
(not your parent commenter)
> For me, programming is about corralling motivation more than anything else. Rust saps my motivation is ways that Zig does not.
Yes, agree with you a lot! Maybe our brains are just wired differently, for me, no other language (until now) gives me as much motivation as Rust, as it's type system and docs make me feel really good.
> Zig is simply a much smaller language than Rust. I use Zig because my brain isn't big enough for either C++ or Rust.
Disclaimer: haven't really tried Zig yet. IMO you don't need to keep the whole of Rust in your brain to use it, I usually can just focus on the business logic as if I make a stupid mistake, the compiler will catch it. That (and the type system) is what makes me more efficient with it than other langs. I also stay clear of lifetimes unless I really need them (which is almost never for application code). An extreme example of the opposite is C, where I need to take care about anything I do as it will just accept anything (e.g. auto casting types) so I need to be vigilant about everything.
All of that said, there are patterns that will just be harder to reason about in Rust, mostly with self-referential things, and if you area already used to using them a lot, this can be a hassle. If you're used to smaller data structures and data-oriented programming, it will be a lot easier.
This is not trying to convince you or anyone else, just showing a different perspective. If you feel better with Zig, use it! Everyone has their own experience.
> All of that said, there are patterns that will just be harder to reason about in Rust, mostly with self-referential things, and if you area already used to using them a lot, this can be a hassle. If you're used to smaller data structures and data-oriented programming, it will be a lot easier.
Also an underrated chance to be forced to learn about Arenas, most of the time.
1)
Yeah, not everyone is mitchellh -- I'd argue that his intuition was right (expecting to find more issues), there's a reason we don't all write C.
That said, it's great to hear that others are having success with Zig and aren't writing very many bugs.
> To me, the tradeoff of a demonstrably small number of bugs in a system software language in return for the demonstrably faster developer velocity (Zig compiles WAY faster than Rust, Zig wraps C/C++ libraries way easier than Rust, Zig cross compiles way more easily, etc.) is a decent tradeoff for my use cases.
Reasonable points! This is one of the reasons I have on my list to consider Zig at all (that and wanting to write more C), it seems people that like it are wonderfully productive in it.
I really like a lot of the design decisions and watch the streams than Andrew and Loris, Tigerbeetle folks and others do to see the decisions they make. Their managed IO approach is certainly interesting and quite powerful.
Dislike some small petty syntax things (whyCamelCaseFunctions()!?), but that's a me thing.
> For me, programming is about corralling motivation more than anything else. Rust saps my motivation is ways that Zig does not.
Agree with this, anecdotally.
> I love what the Oxide folks are doing. Having someone pwn your big server because of a memory bug? Yeah, I'd reach for Rust in their use cases. Or, if I'm handling credit cards, I'll have a very different set of tradeoffs that swing against Zig. (Although, in that case, I'll probably reach for a GC language in that case so that I don't have to think about memory management at all.)
Yup, Typescript works for me here, and usually the hard parts are offloaded to an external service anyway (e.g. Stripe)
> Zig is simply a much smaller language than Rust. I use Zig because my brain isn't big enough for either C++ or Rust. > > I'm not a 10x programmer, but I still want to get stuff done. Zig and C enable me to do that without bending my brain.
I wouldn't put Rust and C++ in the same league there as far as brain size requirements, but point taken!
> Yeah, not everyone is mitchellh -- I'd argue that his intuition was right (expecting to find more issues), there's a reason we don't all write C.
I'd argue this is also down to the debug memory allocators in Zig which run a bunch of checks for things like use-after-free. Again, one of the nice things about Zig is that debug mode isn't dramatically slower than release so you're not inclined to turn it off too soon.
However, one thing that does shock me is that no "reference to stack allocated thing escapes" errors existed. Zig does not help you very much on this front, and I'm stunned that none existed.
> I'd argue this is also down to the debug memory allocators in Zig which run a bunch of checks for things like use-after-free. Again, one of the nice things about Zig is that debug mode isn't dramatically slower than release so you're not inclined to turn it off too soon.
Ah another good point -- also excited for what opens up with regards to this approach with managed/explicit I/O. Pretty obvious that permutation testing of async behavior gets unlocked which is nice. The equivalent in Rust would be loom.
> However, one thing that does shock me is that no "reference to stack allocated thing escapes" errors existed. Zig does not help you very much on this front, and I'm stunned that none existed.
TIL -- is everyone just bolting on asan here and sticking to the clang backend for now?
Hopefully the zig strike force will drop by.
>a language with often comparable performance that is ALSO much safer
There are domains where performance is critical and safety isn't so important (e.g. video games). Zig has an advantage in such domains because of the pervasive support for passing around allocators in the standard library (avoiding hidden allocations, and allowing efficient memory reuse via block allocators), while in the Rust stdlib custom allocators are relatively cumbersome to use (and not easy to prove safe to the compiler).
Agreed, I really like Zig's explicit allocation (and to be fair, lots of people from Rust like it too[0], it's just such an insane lift that who knows when it will stabilize)
The new "managed" async strategy (I was previously mistaken thinking it was the same as sans-io) is also really intriguing IMO, and feels like a fantastic balance (people in Rust are doing this too, but for the unrelated reason of trying to support various async runtimes).
[0]: https://github.com/rust-lang/rust/issues/32838
> Maybe some day I’ll have the brain cells and skill to write code in zig and be confident I’m Not introducing a whole class of gnarly bugs, but it seems like I should just focus my limited brain power on writing high
Llms solve this problem
> be confident I’m Not introducing a whole class of gnarly bugs
I think LLMs are doing the exact opposite
Have you tried using an LLM with Zig? When the training sets are on different language versions and there are breaking changes you may find it challenging.
I actually enjoyed zig because it prevented me from using LLMs to code in this way
I use LLMs almost daily, and they certainly don't "solve" the problem of finding bugs, not even in popular languages like TypeScript. They do help a lot, yes, but they haven't solved it completely.
They can help automate the process. Eg from flask creator: https://youtu.be/tg61cevJthc?si=Kd8azCPwXYeb-gac
Using LLMs on a language you don’t already master is a sure way to introduce a lot of bugs.
My personal experience has been different. We recently onboarded a whole team of Devs on a language none of us mastered and it's been running in prod with only a couple bugs so far in 6 months, much lower than our average with our normal stack that everyone masters
If you think LLMs solve this problem, you should reevaluate your experience level and seniority.
I've said nothing about my experience or seniority in this discussion, so I don't know how they are relevant
> I often wonder why some languages succeed while others falter.
IME language success has very little to do with syntax, and much more to do with stdlib, tooling, library availability, coverage on StackOverflow and all the other things that make solving problems simple.
I vaguely remember a talk given by the creator of ELM called "The Economics of Programming Languages". It's actually really expensive to make a good programming language that's widely used.
Forget about syntax or semantics or unique features or whatever. Having money and resources are the most important factor for a successful language.
Oh boy, I always had this knack for seeing/testing multiple langauges and when I had first discovered nim, I used to watch some nim youtube related content and I remember someone in nim community pointed out about this same video from the creator of elm that you also mention.
So, I think that I had watched the video and honestly, I will watch it now once again since I don't remember it clearly but If I remember, I really liked it.
A quick search points me to the video, though I am not sure https://www.youtube.com/watch?v=XZ3w_jec1v8
Where does the money get spent? Just developer salaries and marketing?
The volume of work required to get a language going practically requires full-time headcount. Language design/compiler, community website, documentation, CI, libraries (json, datetime, regex, database connectors, web server, etc), treesitter IDE plugins. A lot of different required hats.
Sure, you can scrape by with a rag tag group of volunteers, but to ever get to mass adoption requires a lot of work and dedicated resourcing. Zig has been in development for how long now, and that is with the designer now working on it full time.
Yes. Writing a language in your free time means juggling work on the side. Or you can be at Google and get paid to write Go for your job, and get free marketing from it. Even Rust had the backing of Mozilla. Until your "pet" language reaches critical mass that you can sustain yourself and quit your day job, you're fighting the giants.
Salaries, hosting bills, CI bills… most languages do not have a significant marketing budget.
> I often wonder why some languages succeed while others falter.
$$$money$$$
A strong tooling ecosystem needs money, which usually means corporate sponsorship.
> $$$money$$$
Rust (backed by a foundation) won over Go (backed by Google). Oh, and remember Dart (backed by Google)?
Say that Rust "won over" Go is like saying that Python "won over" Java. They are both alive and kicking, and live happily in rather different niches.
I almost always choose Go over Rust when they are similarly suited to something. I only use Rust when Go's safety isn't sufficient. Go is a joy to use, Rust rarely is (in my experience).
I wouldn't say either of them have won. I'd say both are amazing tools, too. We're spoiled for choices these days.
They are used for different things. There are a zillion successful projects in Go. Don't see how Rust won anything.
Dart is doing just fine in the Flutter space.
Rust was backed by Mozilla at first and now it's backed by Amazon, Google, Microsoft and others...
Go and Rust don't compete, Go has a GC, they're in fundamentally different domains. Google also uses Rust, among other languages (C++, Java, Python, Go, JS, etc...).
In what sense did Rust “win over” Go? And since Google loves to kill its side projects fast, no wonder Dart failed.
Sorry, I guess I’m biaised but I see a lot of Rust-based projects on HN and not many in Go, and in the latest StackOverflow survey Rust is way ahead of Go as "admired language" and a language that people want to work with.
Dart is really successful. Just look at the latest release that just came out. It’s a really great language and now runs about as fast as Go while looking as good as Kotlin.
Rust can do everything Go does but Go can't do the same as Rust can.
How about fast compilation? :-\
Developer productivity matters...
Concur on the [special case] of rust: It's in a domain that only has a handful of competitors (For its core competencies of system performing, high-performance programming, and embedded). It has learned from , and made improvements on them.
Mojo is similar to Rust in that case, isn't it?
My understanding is that Mojo has yet to prove itself in this space. They made a lot of claims but at the time few of them were implemented.
They also backed down from the initial claim of full Python compatibility. Which was the entire appeal of the venture. If you cannot seamlessly drop into the Python ecosystem, it is just another scripting language with better architecture to enable faster code.
Mojo is not a scripting language in the usual sense. It is a system programming language more akin to Rust. Their aim is to have better ergonomics than Rust.
Nobody wants a closed source systems language
In practice, Mojo feels like it pivoted to being a pythonic scripting language for CUDA
I really wanted to love nim. I wrote a bunch of tools in it, had fun, and then ultimately rewrote them all in rust. The library situation in nim is just unfortunate, and I say that as someone who uses elixir. That, and the cross compiling took far more effort than getting the same code finished on rust, which was little more than "use cross"
I keep hoping nim will get better, because it's a beautiful language that produces absolutely tiny, efficient binaries
Nim is a programming language for an expert programmer. The ecosystem is very small and for everything a little bit more specialized you need to make a library yourself.
When there's a vacuum like that, that is also an opportunity for folks to make a significant impact.
Compare to other communities where you need to stand out from the noise.
That's plus for individuals but minus for languages.
Personal anecdote: I was exactly there a decade ago when I was working on Chrono, now one of best-known date and time libraries in Rust. Since I was simply my own, my design was not as good as it could have been. Of course it is still much better to have a suboptimal Chrono, but I can't deny that it remains and probably will remain suboptimal due to my design a decade ago.
This usually ends up in a situation where most of the significant libraries for the language are abandoned GitHub repos with 13 stars and no documentation ("You just have to read the code!!1!").
Abandoned (finished) with no docs (read/copy/hack the source). I'm surprised how devs are afraid to look behind the curtain of a library/os/compiler.
Perfect examples of glass-half empty vs glass-half full kinds of people.
This. I really wanted to like Nim. I tried to learn it, but having never been a programmer before (but years of Linux admin, puppet, terraform and scripting) I found it extremely tough, and a lot of documentation is out of date and the there aren't many good examples to follow. Switched to Go and have built lots and lots of stuff in go.
> a lot of documentation is out of date
Please, file bugs or complain on the official matrix room. The community tries its best to keep up the official documentation in sync with the changes.
https://matrix.to/#/#nim-lang:matrix.org
Whenever I’m missing a library I’m usually just 5 mins away from successfully using a C library (or any library with a C API). In my years doing data analysis, signal processing, and just writing plain servers I’ve never once gotten stuck because of a missing library.
Exactly, I had tried nim but I felt the same issue.
I mean, personally I really like golang. Its actually gotten an ecosystem that functions while being able to cross compile and actually being easy enough to learn unlike rust.
I also sometimes exclusively just use typescript/python just for their ecosystem as a junior programmer. For me ecosystem matters a lot and this was a reason why I wish that more languages can create more libraries which can work.
Like the article pointed, nim is really solid language. But I'd like to see more libraries being made for it.
Sounds more like "Expert Hobbyist" than "Expert Programmer".
So, there I was in 2016. It had been 13 years since I had last entertained the desire to learn a new programming language (I had landed on Python, back then). The serious contenders were Go, Nim, and Rust. I landed on Nim back then, thinking to myself: Man, this language really has a future. I did my next side project in Nim, and loved it like I've loved no other language over the course of my (as of now, in 2025) 28 years of programming. But no actual job ever materialized to make me into a professional Nim programmer that would actually pay the bills. I stuck it out with Python, with growing discontentment. I took a Perl job in 2018, which lasted until 2022, which I never should have taken in the first place. I was relatively free in my choice of language from that point forward, and decided to switch from Python to Lua after a short period of disorientation where I kind of liked Haxe. Right now, I'm learning Rust, crying tears over that future for Nim that never materialized.
Had almost the same situation to a tee around the same time (~2014). Decided between Rust, Nim, D and Go. Went with Rust then and quickly felt it had been the right choice since it really helped me improving my skills and got me interested in programming again after a few years away from it. Rust community was way smaller and more approachable, the language felt exciting and really delivered on its promises.
Then around 2019 Nim started to gain momentum (preparing for 1.0 release) and when I looked into it a bit deeper it became evident that for most of the code I usually write for myself Nim is just a more pragmatic choice than Rust. It gets me there faster.
Zero job perspectives both times, scratched my own itch twice though.
Glad I haven't gone with Go. Nim is not a perfect overlap with Rust, but it definitely covers everything Go can do and more and is a better design in my opinion.
Haha. I'm still in the 'this language has a future' phase with OCaml.
You could always go work for Jane Street or... nope thats all I got lol
Honestly, we can all still correct it if we really want to. Nothing is too late in my opinion, but the question that I wish to ask is, is it worth it?
I mean, compared to zig which is starting to have a lot of hype and libraries / help, lets say that we now wish for nim to have this, then are the feature differences b/w zig and nim worth the revival of nim in that sense? (Pardon me if this doesn't make sense)
I fell in love with Nim a couple of years ago, but feel like Zig gaining popularity has really pushed Nim out of the limelight in terms of developer adoption.
Nim has been on my radar for a while, but I've never really dug into it. I have actually written some small projects in Zig though. Are there things you think Nim does better than Zig?
I think Nim and Zig target very different audiences and have very different goals. Nim is about being a big, powerful language with lots of features, so that you have the freedom to use it the way you want, e.g. there is OOP with methods, but it's completely optional. Zig is explicitly against that, even on the homepage you can see: "No hidden control flow. No hidden memory allocations. No preprocessor, no macros.". While memory management in Nim by default is completely automatic, and templates/macros are quite common.
It makes much more sense to compare Nim to, say, Swift, D, or other modern compiled languages with lots of syntax sugar.
You may consider Nim as a sort of "compiled Python" with some Pascal influences.
https://nimble.directory/ I'd pick Nim if my concern is general app development, not specifically system programming.
What a low effort article. I have done some programming in Nim. It’s a nice language but I felt frustrated whenever I wanted to do something I knew I could do in python but that didn’t work in Nim. I just missed some of the syntactic sugar of python, that being said I would love to get back into Nim again.
You know what, I mostly do python, but then had to get quite high performance on some lib. Converting to Nim and importing with nimpy has been a blast. The result is just one more python module, colleagues don't get frightened when they see the code, it's just seamless and nifty. I much prefer it to Cython.
Can you provide some examples if you still remember?
If I remember correctly it was when working with collections but I can’t remember a concrete example though. Their std library is by no means bad it is just different enough from python to hurt my productivity. My initial motivation for chosing Nim was because I was doing an algorithm course at the time and I wanted to archive fastest runtimes in shortest amount of code
I’m also an avid Nim developer (findsight.ai is almost pure Nim).
I recently compiled some stats on Nims popularity on GitHub: https://code.tc/nim-stats-august-2025/
It’s growing steadily but I do qualitatively feel like the ecosystem has lost a bit of steam over the past year. Excited for the ongoing Nim tool chain work though.
> In fact, Nim first compiles to C which in turn is compiled to machine code by the C compiler of your choice (gcc/clang).
Can one use the zig compiler after nim has compiled to C?
Yes, you can use the Zig compiler as a C backend for Nim by setting `--cc:zig` in your Nim compiler flags, which provides better cross-compilation capabilities than traditional C compilers.
Yes, I tried it recently for easy cross-compilation. You can use basically any C/C++ compiler, even TinyCC works (in most scenarios) if you want an extremely fast edit/compile/test cycle.
You can, but zigcc is essentially Clang bundled with extra stuff to make cross compilation easy.
At this point I would feel more enthused to read a "Why not Nim?" page. Advertise where the language is bad at so I can get a better sense of it.
* It hasn't taken off.
* It doesn't have many libraries.
oh nim nim nim nim nim fucking nim
From a promotional marketing perspective, that webpage misses quite a few basics, like linking to the Nim site [0] and explaining what it actually does:
Nim is a statically typed programming language that compiles to native dependency-free executables in C, C++ or JavaScript.
[0] https://nim-lang.org/
So why does nobody ever talk about Haxe in the context of an "everything" language?
Is there anything about Haxe that makes it better than Nim?
Compiles to more languages.
You mean the language also known as NIM, n_iM, and NI_m?
IMHO it is a good choice. You shouldn't have variables around that are different only on one cased character, or because one is snake_case and the other is camelCase. It also avoids the contamination of your code when using for example a C library in snake_case while your library uses camelCase. And finally, you can refactor a library in snake_case to camelCase without breaking dependent code.
The first character is actually not considered for case insensitivity, although it was in the past. :) And case insensitivity itself comes to Nim from Pascal.
The underscore thing gets me more than the case insensitivity, FWIW. We have tools for case insensitive greps, but underscore normalizing ones are rare.
nimgrep
By this logic, C++ is the same as C, C# is a syntax error and PHP should be named $PHP :D
What I’m curious for is something akin to a language abstraction layer.
So you can easily combine codebases written in different languages. I guess something like wasm and llvm.
“Has safety features in place”? I’m sorry, not gonna cut it.
I mean, Nim looks cool, but I’m not sure what it does that is substantially new. Niceties are generally not enough to foster adoption - something real has to be on the table that meaningfully opens up new avenues, unlocks new paths, enables new use cases.
I have the same criticism of Zig.
Nim has one of the most powerful metaprogramming systems out there. Hygienic templates, easy macros, but my favorite is the compile-time functions.
Nim compiler has an embedded VM, so any Nim code (that doesn't rely on FFI) can run at compile time.
I'm sure that's nice, but it's not a game changer. You can do metaprogramming in other languages as well, and maybe those languages get it not quire as right as Nim, but it's not enough to tip the scales.
More powerful than zig's comptime?
Yes, compile-time execution in Nim is very natural, if you mark a variable "const" or use some other ways, you can run almost all pure-Nim code at compile-time without having to modify it.
For me, the killer feature of Nim is that I can just write code without having to constantly fight the language.
You just get to fight now at runtime!
> opens up new avenues, unlocks new paths, enables new use cases.
These are all the same thing.
I would have used Nim if Go didn't happen.
Go is good, but sometimes you need higher performance, which is when one of Rust/Zig/Nim must enter the picture.
Significant whitespace is a dealbreaker for me. I never tried Nim for this reason
I could never understand why people care this much about significant whitespace of all things. This seems like such a non-issue, it should be a minor annoyance at worst. Then again my favorite language is Lisp, so maybe I'm just too much beyond caring about syntax. The only annoying thing about significant whitespace is having to escape a new line sometimes.
But significant whitespace has always made sense to me. You are going to indent your code anyway, so you might as well give the indentation some meaning. I write Python, JavaScript and Lua most of the time, and I never waste any thought on whitespace VS braces VS keyword delimiters.
I can count multiple reasons why someone might dislike significant whitespace. The most evident is that whitespace is... not evident at all! By definition, it's a transparent character: it's extremely difficult to directly count spaces; they can be indirectly counted by comparison with text in the surrounding area. The same principle why we add commas or apostrophes or spaces every 3 digits in big numbers.
As of the "you're going to indent your code anyway" claim, this seems to completely ignore one-liners, either embedded in other documents (onClick=...) or fed to the shell as a quick way to get some work done without spawning new tools.
> You are going to indent your code anyway, so you might as well give the indentation some meaning.
Autoformatters came and fixed that problem. Nobody (except python, haskell and nim coders probably) wastes time indenting code anymore, you save and your code is indented. Nowadays, code that relies on whitespace and has no ending delimiters (like nim and python) gets awkward because the formatters have less information to go on. If your rust or typescript code formats to bad indent or none at all, you have an error.
It's harder to tell where code blocks end just by looking
2, I sometimes want to fuck up the indentation on purpose, if I'm just quickly pasting some code to test if it even works or to mark it as "look at it in 5 minutes from now". Also I can mix spaces and tabs
quick edits it notepad/vim/whatever become painful
also converting tabs to spaces or vice-versa is tiring. A language shouldn't force me to a particular code style
On the other hand, I hate languages that are polluted with ugly bracket noise, so Nim is appealing to me for this reason
It’s subjective, but this is also why I haven’t tried Nim or Crystal. If you like brackets, I’d say try Swift if you want to stay in the natively compiled + GC space.
I don't believe Crystal is whitespace significant?
It uses do/end but parts of it are white space from what I can tell.
It is not whitespace sensitive afaik. This same version works as well
(Scrambled on purpose).Spaces don't copy n paste well and are hard to read/navigate
I hated significant whitespace when I tried Python first time. Years later I found Nim and indentation didn't bother me as much.
Maybe we both just got bad first expression with most popular, but unfortunately not a good language? =)
I've really never understood where this aesthetic preference comes from.
Back when most of my code was in C or C++ (or Java), I was told all the time, sure you can omit these braces for a single-statement block, but you shouldn't, you'll regret it later. You can leave all the code unindented or irregularly indented, it won't matter to the compiler, but you'll appreciate lining it up in the long run. And all that advice was correct; I was better off in the long run, and I saw others come to regret it all the time. But then, over time, I started to wonder why I had to scan past all these diagonal lines of close braces as I read the code. And I cursed that these languages made it too difficult to pull out the inner parts into separate functions, disentangle setup and teardown from the main loop etc. But I also cursed that after putting in the effort (even if was just "using a proper text editor") to make things line up beautifully and in agreement with the logical structure, I still had to take up vertical space with these redundant markers of the logical structure.
Python was my first language using significant whitespace, and it was a breath of fresh air. That was a bit over 20 years ago, I think. I've learned several other programming languages since then, but I never "looked back" in any meaningful way.
Every time I copy paste something in python I have to check the whitespace. Often there's a problem that needs fixing, like the first line indented differently, or everything is off. Sometimes I'm not paying perfect attention and get hard to catch bugs.
I'm now certain that significant whitespace is simply wrong.
Significant whitespace pushes a tooling problem (correct indentation) into the human domain. It might have made sense before autoformatters that run on save, but I agree with you that in today's languages, it's a net negative.
As far as I'm aware, none of the new languages that have seen success in the last ten years (Go, Rust, Swift, Dart, Kotlin) rely on the author to format code correctly - instead, they do it for you. And that's good! That's one less thing the programmer has to worry about!
> Significant whitespace pushes a tooling problem (correct indentation) into the human domain. It might have made sense before autoformatters that run on save, but I agree with you that in today's languages, it's a net negative.
Sorry, I don't follow. There's nothing preventing a tool from re-indenting code when it's pasted (i.e.: considering indentation within the pasted text relative to its first line, and then applying an indentation offset according to where it's pasted), and many already do. It's the same kind of logic that's used to auto-format code in braced languages; arguably simpler unless it's also validating the existing indentation of the pasted text.
And actually, who even is relying on "autoformatters that run on save"? I want the code to look right as I'm writing it, not after. The tools you describe are, to me, about maintaining project standards when multiple people are involved, but fundamentally each person is still making the code look locally, personally right before saving (or committing, since these things are also often done with pre-commit hooks). I can't imagine just typing out whatever slop is syntactically correct and waiting to save the file to fix it. Not when I have a proper text editor that facilitates typing it out the way I want it, taking advantage of awareness of the language syntax.
> none of the new languages that have seen success in the last ten years (Go, Rust, Swift, Dart, Kotlin) rely on the author to format code correctly - instead, they do it for you.
Languages do not and cannot format code. Text editors (including the ones built into IDEs) do. If I type a } and the text changes position, it's not the programming language that did this.
And this is also not better in braced languages. Just as I can input a } on a new line in Vim in a braced language and have it dedent, if I want to write more code in Python that's outside the block, I just press the backspace key and it removes an entire level of indentation. And then I start typing that code, and I don't have to input a newline because I'm already on the line where I want the code to be, because I'm not expected to have a } on a separate line from everything else.
> Sorry, I don't follow. There's nothing preventing a tool from re-indenting code when it's pasted (i.e.: considering indentation within the pasted text relative to its first line, and then applying an indentation offset according to where it's pasted), and many already do. It's the same kind of logic that's used to auto-format code in braced languages; arguably simpler unless it's also validating the existing indentation of the pasted text.
I have not had this work reliably for me - my relatively stock VSCode does not indent the pasted code correctly - but I will freely admit that it could, and that this is a point in favour of good tooling.
> And actually, who even is relying on "autoformatters that run on save"? I want the code to look right as I'm writing it, not after. The tools you describe are, to me, about maintaining project standards when multiple people are involved, but fundamentally each person is still making the code look locally, personally right before saving (or committing, since these things are also often done with pre-commit hooks). I can't imagine just typing out whatever slop is syntactically correct and waiting to save the file to fix it. Not when I have a proper text editor that facilitates typing it out the way I want it, taking advantage of awareness of the language syntax.
Most people who write code in these languages rely on them! Format-on-save is one of the first things one sets up in an ecosystem with high-quality formatters. You can write code that is sloppily formatted but conveys your intent, then save and have it auto-format. It completely reformats formatting as a concern. As they say in Go land: "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."
> Languages do not and cannot format code. Text editors (including the ones built into IDEs) do. If I type a } and the text changes position, it's not the programming language that did this.
These languages ship with first-class robust and performant formatters that encode the language's preferred style; much effort has gone into developing these formatters [0]. For all intents and purposes, they are part of the language, and users of these languages will be expected to use them.
> And this is also not better in braced languages. Just as I can input a } on a new line in Vim in a braced language and have it dedent, if I want to write more code in Python that's outside the block, I just press the backspace key and it removes an entire level of indentation. And then I start typing that code, and I don't have to input a newline because I'm already on the line where I want the code to be, because I'm not expected to have a } on a separate line from everything else.
I just don't think about it. I write my code in whatever way is easiest to type - including letting the editor auto-insert closing braces - and then hit save to format.
In general, you are freed from formatting as a matter of concern. It's just not something you have to think about, and that's liberating in its own way; it makes bashing some code out, or pasting some code in, trivial.
[0]: https://journal.stuffwithstuff.com/2015/09/08/the-hardest-pr...
I've been certain that copy & pasting code is simply wrong for a long time, but if the ease of doing this is your yardstick for language design quality, then you are simply right.
Yes, optimize for the thing you do once in a great while over having to read/type redundant braces constantly. Wouldn’t want to have to pay attention and use the tab key! ;-)
I have just the thing for you ;)
https://github.com/xigoi/nimdenter
Wouldn't just adding an "end" to the compounds suffice? An alternative syntax might be a good idea, but #{ and #} looks pretty noisy.
Hello, Python Critic from the 1990's. Welcome to the future
Hello fellow programmer from the middle ages; we discovered long ago that significant whitespace is a dead end, the fact that it's popular with the wannabes changes nothing.
The main reason I never got into Nim is that I seem to recall it depending on mingw and that frankly always sets a language into a second-class category for me. Maybe now it’s different, I don’t know.
Nim is nice but I can't really find a use for it. Maybe it's because I started out on dynamic languages (Ruby and R) where I got used to writing in a dynamic language and then rewriting bottlenecks in C++.
Nim is in the awkward middle area where it's got a GC so it'll never replace C/C++ but it also isn't as productive as something like Ruby.
Nim 2 does not have a mandatory gc.
It is recommended to use ARC, which has similar semantics to C++, ie moves, copies, etc.
Unlike D, the GC is not mandatory for the standard library.