Hacker News Reader

Comment by behnamoh | Hacker News Reader

Counter point: AI makes mainstream languages (for which a lot of data exists in the training data) even more popular because those are the languages it knows best (ie, has the least rate of errors in) regardless of them being typed or not (in fact, many are dynamic, like Python, JS, Ruby).

The end result? Non-mainstream languages don't get much easier to get into because average Joe isn't already proficient in them to catch AI's bugs.

People often forget the bitter lesson of machine learning which plagues transformer models as well.

View on HN

It’s good at matching patterns. If you can frame your problem so that it fits an existing pattern, good for you. It can show you good idiomatic code in small snippets. The more unusual and involved your problem is, the less useful it is. It cannot reason about the abstract moving parts in a way the human brain can.

>It cannot reason about the abstract moving parts in a way the human brain can.

Just found 3 race conditions in 100 lines of code. From the UTF-8 emojis in the comments I'm really certain it was AI generated. The "locking" was just abandoning the work if another thread had started something, the "locking" mechanism also had toctou issues, the "locking" also didn't actually lock concurrent access to the resource that actually needed it.

> UTF-8 emojis in the comments

This is one of the "here be demons" type signatures of LLM code generation age, along with comments like

// define the payload struct payload {};

Yes, that was my point. Regardless of the programming language, LLMs are glorified pattern matchers. A React/Node/MongoDB address book application exposes many such patterns and they are internalised by the LLM. Even complex code like a B-tree in C++ forms a pattern because it has been done many times. Ask it to generate some hybrid form of a B-tree with specific requirements, and it will quickly get lost.

"Glorified pattern matching" does so much work for the claim that it becomes meaningless.

I've copied thousands of lines of complex code into an LLM asking it to find complex problems like race conditions and it has found them (and other unsolicited bugs) that nobody was able to find themselves.

Oh it just pattern matched against the general concept of race conditions to find them in complex code it's never seen before / it's just autocomplete, what's the big deal? At that level, humans are glorified pattern matchers too and the distinction is meaningless.

LLMs are good at needle in the haystack problems, specifically when they have examples in the corpus.

The counter point is how LLMs can't find a missing line in a poem when they are given the original.

PAC learning is basically existential quantification...has the same limits too.

But being a tool to find a needle is not the same as finding all or even reliability finding a specific needle.

Being being a general programming agent requires much more than just finding a needle.

> The counter point is how LLMs can't find a missing line in a poem when they are given the original.

True, but describing a limitation of the tech can't be used to make the sort of large dismissals we see people make wrt LLMs.

The human brain has all sorts of limitations like horrible memory (super confident about wrong details) and catastrophic susceptibility to logical fallacies.

> super confident about wrong details

Have you not had this issue with LLMs? Because I have. Even with the latest models.

I think someone upthread was making an attempt at

> describing a limitation of the tech

but you keep swatting them down. I didn’t see their comments as a wholesale dismissal of AI. They just said they aren’t great at sufficiently complex tasks. That’s my experience as well. You’re just disagreeing on what “sufficiently” and “complex” mean, exactly.

> humans are glorified pattern matchers too and the distinction is meaningless.

I'm still convinced that this is true. The more advances we make in "AI" the more i expect we'll discover that we're not as creative and unique as we think we are.

I suspect you're right. The more I work with AI, the more clear is the trajectory.

Humans generally have a very high opinion of themselves and their supposedly unique creative skills. They are not eager to have this illusion punctured.

maybe you aren't...

Whether or not we have free will is not a novel concept. I simply side on us being more deterministic than we realize, that our experiences and current hormone state shape our output drastically.

Even our memories are mutable. We will with full confidence recite memories or facts we've learned just moments ago which are entirely fictional. Normal, healthy adults.

Humans can't be glorified pattern matchers because they recognize that they aren't.[1]

[1]https://ai.vixra.org/pdf/2506.0065v1.pdf

The paper is satire, but it's a pretty funny read.

LLMs should definitely be used for brute force searches especially of branching spaces. Use them for what they do best.

“Pattern matching” is thought of as linear but LLMs are doing something more complex, it should be appreciated as such.

> it has found them (and other unsolicited bugs) that nobody was able to find themselves.

How did you evaluate this? Would be interested in seeing results.

I am specifically interested in the amount of false issues found by the LLM, and examples of those.

Well, how do you verify any bug? You listen to someone's explanation of the bug and double check the code. You look at their solution pitch. Ideally you write a test that verifies the bug and again the solution.

There are false positives, and they mostly come from the LLM missing relevant context like a detail about the priors or database schema. The iterative nature of an LLM convo means you can add context as needed and ratchet into real bugs.

But the false positives involve the exact same cycle you do when you're looking for bugs yourself. You look at the haystack and you have suspicions about where the needles might be, and you verify.

> Well, how do you verify any bug?

You do or you don't.

Recently we've seen many "security researchers" doing exactly this with LLM:s [1]

1: https://www.theregister.com/2025/05/07/curl_ai_bug_reports/

Not suggesting you are doing any of that, just curious what's going on and how you are finding it useful.

> But the false positives involve the exact same cycle you do when you're looking for bugs yourself.

In my 35 years of programming I never went just "looking for bugs".

I have a bug and I track it down. That's it.

Sounds like your experience is similar to using deterministic static code analyzers but more expensive, time consuming, ambiguous and hallucinating up non-issues.

And that you didn't get a report to save and share.

So is it saving you any time or money yet?

Oh, I go bug hunting all the time in sensitive software. It's the basis of test synthesis as well. Which tests should you write? Maybe you could liken that to considering where the needles will be in the haystack: you have to think ahead.

It's a hard, time consuming, and meandering process to do this kind of work on a system, and it's what you might have to pay expensive consultants to do for you, but it's also how you beat an expensive bug to the punchline.

An LLM helps me run all sorts of considerations on a system that I didn't think of myself, but that process is no different than what it looks like when I verify the system myself. I have all sorts of suspicions that turn into dead ends because I can't know what problems a complex system is already hardened against.

What exactly stops two in-flight transfers from double-spending? What about when X? And when Y? And what if Z? I have these sorts of thoughts all day.

I can sense a little vinegar at the end of your comment. Presumably something here annoys you?

> I can sense a little vinegar at the end of your comment. Presumably something here annoys you?

Thanks for your responses.

Really sorry about the vinegar, not intentional. I may have such personality disorder idk. Being blunt, not very great communication skills.

It's ok, I do worse things on HN.

My vice is when someone writes a comment where I have a different opinion than them, and their comment makes me think of my own thoughts on the subject.

But since I'm responding to them, I feel like it's some sort of debate/argument even though in reality I'm just adding my two cents.

> It can show you good idiomatic code in small snippets.

That's not really true for things that are changing a lot. I got a terrible experience last time I've tried to use Zig, for example. The code it generated was an amalgamation between two or three different versions.

And I've even got this same style of problem in golang where sometimes the LLM generates a for loop in the "old style" (pre go 1.22).

In the end LLMs are a great tool if you know what needs to be done, otherwise it will trip you up.

Humans cannot reason about code at scale. Unless you add scaffolding like diagrams and maps and …

Things that most teams don’t do or half-ass

Its not scaffolding if the intelligence itself is adding it. Humans can make their own diagrams ajd maps to help them, LLM agentsbneed humans to scaffold for them, thats the setup for the bitter lesson

From what I can tell, LLMs tend to hallucinate more with minor languages than with popular ones. I'm saying this as a Scala dev. I suspect most discussions about the LLM usefulness depend on the language they use. Maybe it's useful for JS devs.

I write primarily Scala too. The frontier models seem reasonably good at it to me. One approach I sometimes use is to ask for it to write something complicated in Python, using only the standard library, and then once I have the Python refined I ask for a translation into Scala. This trick may not be applicable to your problems, but it works for me when I find an interesting algorithm in a paper and I'd like to use it but there is no existing Java/Scala implementation.

I use AI assistance to generate code and review code, but I haven't had success trying to use it to update a substantial existing code base in Scala. I have tried using both Claude Code and Cursor and the handful of times I tried there were so many oversights and mistakes that resolving the mess was more effort than doing it manually. I'll probably try again after the next big model releases.

Current frontier models have been the least useful to me when I'm asking them to review performance-critical code inside Scala. These are bits of my code base that I have written to use a lot of mutable variables, mutable data structures, and imperative logic to avoid allocations and other performance impediments. I only use this style for functions highlighted by profiling. I can ask for a code review and even include the reasoning for the unusual style in the docstring, but Claude and Gemini have still tried to nudge me back to much slower standard Scala idioms.

problem with the tools you're using is that they're not built for code review

im building one that lets you write and enforce your own rules so you don't get the typical slop

email in profile if you'd like to try it - i can send you a link

Its more useful for python devs since pretty much all ml code is python wrappers around c++.

Cursor and Claude Code were the asskicking I needed to finally get on the typescript bandwagon.

Strong typing drastically reduces hallucinations and wtf bugs that slip through code review.

So it’ll probably be the strongly typed languages that receive the proportionally greatest boost in popularity from LLM-assisted coding.

This is why I like Go for vibe programming.

goimports makes everything look the same, the compiler is a nitpicky asshole that won’t let the program even compile if there is an unused variable etc.

> won’t let the program even compile if there is an unused variable

That is a really big advantage in the AI era. LLMs are pretty bad at identifying what is and what isn't relevant in the context.

For developers this decision is pretty annoying, but it makes sense if you are using LLMs.

Yep, that's why I like strict tooling with LLMs (and actually real people as well, but that's a different conversation :D)

When you have a standard build process that runs go vet, go test, golanci-lint, goimports and compiles the code you can order the LLM to do that as the last step every time.

This way at the very least the shit it produces is well-formed and passes the tests :)

Otherwise they tend to just leave stuff hanging like "this erroring test is unrelated to the current task, let's just not run it" - ffs you just broke it, it passed perfectly before you started messing with the codebase =)

I’m having a good time with claude and Elm. The correctness seems to help a lot. I mean it still goes wonky some times, but I assume that’s the case with everyone.

Most people who work in non-mainstream languages are, to some extent, making a statement. They care more about X than mere "popularity". (Sometimes X is money, hence why I still have Anki flashcards in rotation on OCaml, Intersystems Cache and Powershell.)

If they do want "popularity" then the counter-counter-point is that it should be easier to get than ever. Just have one proficient person write a lot of idiomatic, relatively isolatable code, and then have an AI generate terabytes upon terabytes of public domain licensed variations and combinations on that code. If you make programming in the small a breeze, people will flock to your language, and then they can discover how to program in the large with it on their own time.

I'm not sure, I have a custom config format that combines a CSV schema with processing instructions that I use for bank CSVs and Claude was able to generate a perfect one for a new bank only based on one config plus CSV and the new bank's CSV.

I'm optimistic that most new programming languages will only need a few "real" programmers to write a small amount of example code for the AI training to get started.

> I'm optimistic that most new programming languages will only need a few "real" programmers to write a small amount of example code for the AI training to get started.

CSV is not a complex format.

Why do you reach this conclusion from toying with CSV?

And why do you trust a LLM for economic planning?

It’s not “economic planning”, it’s creating a CSV parser/converter.

When the code is done, it not like the LLM can secretly go flip columns at random

More people who are not traditionally programmers are now writing code with AI assistance (great!) but this crowd seems unlikely to pick up Clojure, Haskell, OCaml etc... so I agree this is a development in favor of mainstream languages.

Imo there's been a big disconnect between people who view code as work product vs those who view it as a liability/maintenance burden. AI is going to cause an explosion in the production of code, I'm not sure it's going to have the same effect on long term maintenance and I don't think rewriting the whole thing with ai again is a solution.

Any they don’t understand it. So they get something that kinda half works and then they’re screwed.

Not sure.

Even for small projects the optimisation criteria is different if the human's role in the equation shifts from authoring to primarily a reviewing based one.

Yes, I worry that we're in for an age of stagnation, where people are hesitant to adopt radically new languages or libraries or frameworks because the models will all be bad at them, and that disadvantage will swamp any benefit you might get from adopting an improved language/library/framework.

Alternatively every new release will have to come with an MCP for its documentation and any other aspects that might make it easier for an LLM to talk about it and use it accurately.

Can confirm, you can do some good vibe coding with JavaScript (or TypeScript) and Claude Code. I once vibe coded a test suite for a complex OAuth token expiry issue while working on someone else's TypeScript code.

Also, I had created a custom Node.js/JavaScript BaaS platform with custom Web Components and wanted to build apps with it, I gave it the documentation as attachment and surprisingly, it was able to modify an existing app to add entire new features. This app had multiple pages and Claude just knew where to make the changes. I was building a kind of marketplace app. One time it implemented the review/rating feature in the wrong place and I told it "This rating feature is meant for buyers to review sellers, not for sellers to review buyers" and it fixed it exactly right.

I think my second experience (plain JavaScript) was much more impressive and was essentially frictionless. I can't remember it making a single major mistake. I think only once it forgot to add the listener to handle the click event to highlight when a star icon was clicked but it fixed it perfectly when I mentioned this. With TypeScript, it sometimes got confused; I had to help it a lot more because I was trying to mock some functions; the fact that the TypeScript source code is separate from the build code created some confusion and it was struggling to grep the codebase at times. Though I guess the code was also more complicated and spread out over more files. My JavaScript web components are intended to be low-code so it's much more succinct.

Recently I wrote a significant amount of zig first time in my life thanks to Claude Code. Is zig a mainstream language yet?

It's not too obscure. It's also about the point where some coding LLMs get weak.

Zig changes a lot. So LLMs reference outdated data, or no data at all, and resort to making a lot of 50% confidence guesses.

Interesting, my experience lerning Zig was that Claude was really bad at the language itself to the point it wrote obvious syntax errors and I had to touch up almost everything.

With Rust OTOH Claude feels like a great teacher.

Syntax and type errors gets instantly picked up by type checker and corrected, and as long as these failures stay in context, LLM doesn’t make those mistakes again. Not something I ever have to pay attention to.

AI seems pretty good at Rust, so I don't know. What sort of obscure languages are we talking about here?

Haskell, Lisps (especially the most Common one!), Gleam or any other Erlang-wrapper like Elixir, Smalltalk, etc.

Phoenix.new is a good example of a coding agent that can fully bootstrap realtime Elixir apps using Phoenix LiveView: https://phoenix.new/

I also use coding agents with Elixir daily without issues.

See this is what kills me about these things. They say they built this system that will build apps for you, yet they advertise it using a website that chews through my CPU and GPU. All this page does is embed a YouTube video, why is my laptop's fan going full blast? And I'm supposed to trust the code that emanates from their oracle coding agent? What are we doing here people??

Yes, Claude 4 is very good at Elixir.

Old stuff like VB.NET it’s really struggling on here. But c# its mostly fine

Rust is far from obscure.

some HDLs should fit the bill: VHDL, Verilog or SystemC

I taught Digital Design this semester - all models output nonsensical VHDL. The only exception is reciting “canonical” components available on technical and scientific literature (e.g., [1]).

[1] https://docs.amd.com/r/en-US/ug901-vivado-synthesis/Flip-Flo...

Rust is the absolute winner of LLM era.

By what metric? I still see vastly more Python and Typescript being generated, and hell, even more golang. I suppose we are all in our own language bubbles a bit.

Python code generated by LLM is like a landmine; it may compile, but there could be runtime errors lurking that will only detonate when the code is executed at some undetermined point in the future.

Rust code has the property that if it compiles, it usually works. True there are still runtime errors that can occur in Rust, but they're less likely going to be due to LLM hallucinations, which would be caught at compile time.

I mean, that is true for any interpreted language. That's why have type checkers, LSPs, tests and so on. Still not bullet proof, but also not complete time bomb like some commenters make it out to be. Hallucinations are not an issue in my day to day, stupid architecture decisions and overly defensive coding practices, those more so.

Right, that's why good language design is still relevent in 2025. e.g. type checking only saves you if the language design and ecosystem is amenable to type checking. If the LLM can leverage typing information to yield better results, then languages with more type annotations throughout the code and ecosystem will be able to extract more value from LLMs in the long term.

> overly defensive coding practices

Can you elaborate a bit here? In my experience, most code I come into contact with isn't nearly defensive enough. Is AI generated code more defensive then the median?

I don’t have hard data to back it up, but LLMs make writing code super easy now. If the code compiles, you’ve basically filtered out the hallucinations. That’s why writing in Python or TypeScript feels kind of pointless. Rust gives you memory safety, no garbage collector, and just overall makes more sense, way better than Go. Honestly, choosing anything other than Rust feels like a risky gamble at this point.

Rust only really makes sense in settings where you would have otherwise used C or C++, i.e. you need the best possible performance and/or you can't afford garbage collection. Otherwise just use Go, Java or C#. There is no gamble with picking any of these.

Rust is fantastic for writing HTTP servers, microservices, and desktop applications.

OpenAI uses Rust for their service development as do a lot of other big companies.

It's a lot like Python/Flask, or even a bit like Go. It's incredibly easy to author [1] and deploy, and it runs super fast with no GC spikes or tuning. Super predictable five nines.

Desktop apps sing when written in Rust. A lot of AI powered desktop apps are being written in Rust now.

If you're going to reach for Go or Java (gRPC or Jetty or something) or Python/Flask, Rust is a super viable alternative. It takes the same amount of time to author, and will likely be far more defect free since the language encourages writing in a less error prone way and checks for all kinds of errors. Google did a study on this [2,3].

[1] 99.9% of the time you never hit the borrow checker/lifetimes when writing server code as it's linear request scoped logic. You get amazing error handling syntax and ergonomics and automatic cleanup of everything. You also have powerful threading and async tools if you need your service to do work on the side, and those check for correctness.

[2] "When we've rewritten systems from Go into Rust, we've found that it takes about the same size team about the same amount of time to build it," said Bergstrom. "That is, there's no loss in productivity when moving from Go to Rust. And the interesting thing is we do see some benefits from it. So we see reduced memory usage in the services that we've moved from Go ... and we see a decreased defect rate over time in those services that have been rewritten in Rust – so increasing correctness." https://www.theregister.com/2024/03/31/rust_google_c/

[3] https://news.ycombinator.com/item?id=39861993

> Rust is fantastic for writing HTTP servers, microservices, and desktop applications.

In which world is Rust fantastic for writing desktop applications? Where are the mature Rust UI frameworks?

> Desktop apps sing when written in Rust.

What does this even mean?

> A lot of AI powered desktop apps are being written in Rust now.

For example? And what do you mean by "AI powered desktop apps"?

> In which world is Rust fantastic for writing desktop applications? Where are the mature Rust UI frameworks?

Rust has come a remarkably long way [1] !

It's better than any language that isn't C/C++. We have bindings to all of the major UI toolkits, plus a lot of native toolkits.

You can also use Electron/Tauri for Javascript, or Dioxus for something more performant. Egui is also really nice for dev tools.

> What does this even mean?

Rewrite It In Rust metrics tend to tell good stories.

Developer blogs (links escaping me right now) show positive performance gains for lots of consumer desktop software written in whole or in parts using Rust. Discord, Slack, lots of other apps are starting to replace under-performing components in Rust.

> For example? And what do you mean by "AI powered desktop apps"?

Stuff like Zed [2] and the open source Photoshop-killer I'm working on (user-guided volumetric rendering, real time instructive Figma). The creator or egui works on Rerun [3], which is industrial / spatial visualization. Etc, etc.

[1] https://areweguiyet.com/

[2] https://zed.dev/

[3] https://rerun.io/

> [1] https://areweguiyet.com/

The only mature cross-platform UI frameworks I see in this list are written in C and C++ :) And of all the various Rust bindings for Qt, only a single one ("ritual") offers bindings to the Widgets API. Not only are these bindings unsafe, the project has also been abandoned. https://github.com/KDAB/cxx-qt/?tab=readme-ov-file#compariso.... Of course, this is not suprising, given that the API surface of Qt6 is huge and difficult (or impossible?) to safely wrap in Rust.

(The reality is that Rust's ownership model makes it rather awkward to use for traditional UI frameworks with object trees.)

Tauri looks neat, but the actual UI is a webview, so it's not everyone's cup of tea. (Certainly not mine.)

As you said, egui is cool for simple tools, but not suitable for complex desktop applications.

Yes, Rust has gotten quite a few desktop UI frameworks, but I don't see any industry standards yet. Don't forgot that Qt has been in development for 30 years now! Rust has a lot to catch up.

If you use an LLM with C or C++, stuff like pointer arithmetic or downcasting can be tricky. The code might compile just fine, but you could run into problems at runtime. That's why Rust is the only way...

> The code might compile just fine, but you could run into problems at runtime.

Obviously, this can also happen with Rust, but certainly less so than with C or C++, I'll give you that. But how is Rust the only way when there's also Java, Go, C#, Swift, Kotlin, etc.?

Does nobody write business logic in Rust? All you ever hear is “if it compiles it works” but you can write a compiling Rust program that says “1 + 1 = 3”. Surely an LLM can still hallucinate.

you also write units tests, which is something baked in rust std toolchain.

same i am developing a bunch of neovim plugins. haven't had any background in neovim or lua.

I’m blown away by how good Gemini Pro 2.5 is with Rust. Claude I’ve found somewhat disappointing, although it can do focused edits okay. Haven’t tried any of the o-series models.

Ehhhh, a year ago I'd have agreed with you — LLMs were noticeably worse with Elixir than with bigger langs.

But I'm not noticing that anymore, at least with Elixir. The gap has closed; Claude 4 and Gemini 2.5 both write it excellently.

Otoh, if you wanted to create an entirely new programming language in 2025, you might be shit outta luck.

Unless the new language was a super set of an existing language. I think a stricter version of python or even typescript could be do-able.

Good point

> Otoh, if you wanted to create an entirely new programming language in 2025, you might be shit outta luck.

This just made me really sad. That effectively means that we'll plateau indefinitely as a civilization (not just on programming languages, but anything where the LLM can create an artificial Lindy effect).

> Otoh, if you wanted to create an entirely new programming language in 2025, you might be shit outta luck.

Or, do what you want, and don't worry what language people who have no interest in programming use.

Reply on news.ycombinator.com