Hacker News Reader

> 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).

I’d say the majority of Nim’s stdlib can be used without ref (arc) types. The compiler only generates ARC code if you use ref types not when you import a module.

Yeah much of the basic stdlib only uses vector, string, and map types which are similar to C++ & Rust ones with single ownership and move semantics. Static arrays can be used with many basic functions like sort.

The JSON module in Nim’s stdlib does use ref ARC types. However neither C++ nor Rust provide a JSON module by default.

Actually, a fair bit of Nim’s stdlib can even be used without allocators! Unlike Rust’s #[no_std] for embedded which is just a pain.

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.

Not really, because they are not Automated Reference Counting, rather manual with explicit clone operations, in some scenarios.

Also contrary to systems where reference counting is part of the type system, and not library types, they aren't able to optimize counts away.

When this happens is as side effect of the compiler optimizing away inlined code, but not by pairing inc() with dec() operations that never leave scope.

>The notion that we need to all program in the top 10 popular programming languages seems dead with the advent of LLMs.

It was dead prior to this. A subset of programmers think it's hard to program in any other language other than the one or two they studied.

They are wrong. Most programming languages are very very similar. And learning one means you learned almost all. i learned new languages on the regular pre - llms and it required barely any effort.

Most company interviews are also language agnostic for this reason. Because languages are so trivial to learn once you "get" how to program.

It’s like human language: your second one is hard, your fifth one is easy.

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.

Why are there hundreds of food recipes in the world? Shouldn't the most delicious dish just kill all the others? In the end there will be only one dish and we will all eat only that.

This is what human languages tried to do but then they discovered nukes and now they’re all at a stalemate.

> Most programming languages are very very similar.

For the most part, yes. I'd add the caveat of needing to differentiate significantly between imperative and functional programming, though. I've used Python, Java, C, C++, C#, PHP, and a TINY bit of Perl (Enough to know it's a terrible language -- seriously, why would anybody want to use a language that people refer to as "write-only" because it's so hard to read?), and Haskell just makes no damn sense to me. It seems its only use is to show off how Quicksort can be written in two lines with it, or to start fights over whatever the hell a Monad is.

Also, if you've only ever written in memory-safe languages like Python, Java, and C#, then switching to an unsafe language like C or C++ will probably result in writing a ton of memory leaks, buffer overflows, and segfaults.

You only say that about Haskell because you don’t understand it. Once you understand i, your world view will change.

Technically you didn’t specify if your world view will improve or devolve. ;)

It depends on if you prefer the red pill or the blue pill.