Live data from Hacker News

Any application that can be written in a system language, eventually will be

avraam.dev

31–40 of 132 posts

Re: Any application that can be written in a system language, eventually will be

#31

I wonder when we'll start to see languages designed exclusively to be easy to write by agent programming.

It seems the language would need to be strongly typed, have good error reporting and testing infrastructure, have a good standard library and high-level abstractions, and be "close enough" to existing languages. Go would seem to already fit that bill, any bespoke language you come up with is going to have less exposure in the training set than Go. Maybe Rust as a second, but Go's memory management might be easier for…

Rust, Go and TypeScript are good bets.

Python too -- hear me out. With spec-driven development to anchor things, coupled with property-based tests (PBT) using Hypothesis, it's great for prototyping problems.

You wouldn't write mission critical stuff with it, but it has two advantages over so-called "better designed languages": massive ecosystem and massive training.

If your problem involves manipulating dataframes (polars, pandas), plotting (seaborn), and machine learning, Python just can't be beat. You can try using an LLM to generate Rust code for this -- go ahead and try it -- and you'll see how bad it can be.

Better ecosystems and better training can beat better languages in many problem domains.

Re: Any application that can be written in a system language, eventually will be

#32

I don't really want to learn how to use the borrow checker, LLM help or not, and I don't really want to use a language that doesn't have a reputation for very fast compile/dev workflow, LLM help or not. Re; Go, I don't want to use a language that is slower than C, LLM help or not. Zig is the real next Javascript, not Rust or Go. It's as fast or faster than C, it compiles very fast, it has fast safe release modes. It…

Writing code without the borrow checker is the same as writing code with the borrow checker. If it wouldn't pass the borrow checker, you're doing something wrong.

Idk. Did you see the "Buffer reuse" section of this blog post? [1]

Kudos to that guy for solving the puzzle, but I really don't want to use a special trick to get the compiler to let me reuse a buffer in a for loop.

[1]: https://davidlattimore.github.io/posts/2025/09/02/rustforge-...

Re: Any application that can be written in a system language, eventually will be

#33

I don't really want to learn how to use the borrow checker, LLM help or not, and I don't really want to use a language that doesn't have a reputation for very fast compile/dev workflow, LLM help or not. Re; Go, I don't want to use a language that is slower than C, LLM help or not. Zig is the real next Javascript, not Rust or Go. It's as fast or faster than C, it compiles very fast, it has fast safe release modes. It…

Writing code without the borrow checker is the same as writing code with the borrow checker. If it wouldn't pass the borrow checker, you're doing something wrong.

This is a n objectively false statement.

Rusts borrow checker is only able to prove at compile-time that a subset of correct programs are correct. There are many correct programs that the BC is unable to prove to be correct and therefore rejects them.

I’m a big fan of Rust and the BC. But let’s not twist reality here.

Re: Any application that can be written in a system language, eventually will be

#34

> in 2026 devs write 90% of the code using natural language, through an LLM. That is literally not true - is the author speaking about what he personally sees at his specific workplace(s)? If 90% of the code at any given company is LLM-generated that is either a doomed company or a company doesn't write any relevant code to begin with. I literally cannot imagine a serious company in which that is a viable scenario.

If there's a human in then loop, actually reading the plans and generated code, then it's possible to have 90% of me code generated by an LLM and maintain reasonable quality.

Re: Any application that can be written in a system language, eventually will be

#35

While I still struggle to think in Rust after years of thinking in C, it is NEVER the borrow checker or lifetimes that trip me, it's the level of abstraction, in that C forced me low level, building my own abstractions, while Rust allows me to think in abstractions first and muse over how to implement those idiomatically. What did it for me was thinking through how mutable==exclusive, non-mutable==shared, and getting…

Thank you for this comment.

I'm starting my rusty journey and I'm only a few months in. With the rise of autogenerated code, it's paradoxically much harder to go slow and understand the fundamentals.

Your comment is reassuring to read.

Re: Any application that can be written in a system language, eventually will be

#36

> in 2026 devs write 90% of the code using natural language, through an LLM. That is literally not true - is the author speaking about what he personally sees at his specific workplace(s)? If 90% of the code at any given company is LLM-generated that is either a doomed company or a company doesn't write any relevant code to begin with. I literally cannot imagine a serious company in which that is a viable scenario.

Yeah, I would say it's pretty variable, and it depends on what you mean by the word write.

I've recently joined a startup whose stack is Ruby on Rails + PostgreSQL. Whilst I've used PostgreSQL, and am extremely familiar with relational databases (especially SQL Server), I've never been a Rubyist - never written a line of Ruby until very recently in fact - and certainly don't know Rails, although the MVC architecture and the way projects are structured feels very comfortable.

We have what I'll describe as a prototype that I am in the process of reworking into a production app by fixing bugs, and making some pretty substantial functional improvements.

I would say, out of the gate, 90%+ of the code I'm merging is initially written by an LLM for which I'm writing prompts... because I don't know Ruby or Rails (although I'm picking them up fast), and rather than scratch my head and spend a lot of time going down a Google and Stackoverflow black hole, it's just easier to tell the LLM what I want. But, of course, I tell it what I want like the software engineer I am, so I keep it on a short leash where everything is quite tightly specified, including what I'm looking for in terms of structure and architectural concerns.

Then the code is fettled by me to a greater or lesser extent. Then I push and PR, and let Copilot review the code. Any good suggestions it makes I usually allow it to either commit directly or raise a PR for. I will often ask it to write automated tests for me. Once it's PRed everything, I then both review and test its code and, if it's good, merge into my PR, before running through our pipeline and merging everything.

Is this quicker?

Hmm.

It might not be quicker than an experienced Rails developer would make progress, but it's certainly a lot quicker than I - a very inexperienced Rails developer - would make progress unaided, and that's quite an important value-add in itself.

But yeah, if you look at it from a certain perspective, an LLM writes 90% of my code, but the reality is rather more nuanced, and so it's probably more like 50 - 70% that remains that way after I've got my grubby mitts on it.

Re: Any application that can be written in a system language, eventually will be

#37

> in 2026 devs write 90% of the code using natural language, through an LLM. That is literally not true - is the author speaking about what he personally sees at his specific workplace(s)? If 90% of the code at any given company is LLM-generated that is either a doomed company or a company doesn't write any relevant code to begin with. I literally cannot imagine a serious company in which that is a viable scenario.

I can believe LLM generated after being cut up into small slices that are carefully reviewed. But to have 20 copies of Claude Code running simultaneously and the code works so well you don't need testers == high on your own supply.

> high on your own supply.

reminds me of a bar owner who died of liver failure. people said he himself was his best customer

Re: Any application that can be written in a system language, eventually will be

#38

> in 2026 devs write 90% of the code using natural language, through an LLM. That is literally not true - is the author speaking about what he personally sees at his specific workplace(s)? If 90% of the code at any given company is LLM-generated that is either a doomed company or a company doesn't write any relevant code to begin with. I literally cannot imagine a serious company in which that is a viable scenario.

That depends on how you define "doomed". Most screwed up companies don't go belly up overnight. They get sold as fixer-uppers and passed between bigger firms and given different names until, finally, it is sold for parts. The way this works is that all parties behave as if the company is the opposite of doomed. It's in a sense correct. The situation hardly seems doomed if everyone has enough time to make their money and split before the company's final death twitches cannot be denied, in which case the company accomplished its mission. That of course doesn't mean everything from its codebase to its leadership didn't lack excellence the whole time.

Re: Any application that can be written in a system language, eventually will be

#39

> in 2026 devs write 90% of the code using natural language, through an LLM. That is literally not true - is the author speaking about what he personally sees at his specific workplace(s)? If 90% of the code at any given company is LLM-generated that is either a doomed company or a company doesn't write any relevant code to begin with. I literally cannot imagine a serious company in which that is a viable scenario.

In my experience, most of the NodeJS shops do this. Because, LLMs on the surface seemingly are good at giving you a quick solution for JS code. Whether it's a real solution or patchwork is up for debate, but, for most mid-level to junior devs, it's good enough to get the job done. Now, multiply this workflow 10x for 10 employees. That's how you end up with a complete rewrite and hiring a senior consultant.

Re: Any application that can be written in a system language, eventually will be

#40
post #35

While I still struggle to think in Rust after years of thinking in C, it is NEVER the borrow checker or lifetimes that trip me, it's the level of abstraction, in that C forced me low level, building my own abstractions, while Rust allows me to think in abstractions first and muse over how to implement those idiomatically. What did it for me was thinking through how mutable==exclusive, non-mutable==shared, and getting…

Thank you for this comment. I'm starting my rusty journey and I'm only a few months in. With the rise of autogenerated code, it's paradoxically much harder to go slow and understand the fundamentals. Your comment is reassuring to read.

Just wanted to add another bit of reassurance. At some point during my career people started "stack overflow coding". But ultimately someone has to fix the difficult issues and when you have the skills, you are coming out on top where others can just shrug and say "well there's no solution on stack overflow".
Post reply on HN