61–70 of 132 posts
Why stop at a systems language? Why not assembly? Hell why not raw machine code? You have to rewrite it for every new processor? Big deal. Llm magic means that cost isn't an issue and a rewrite is just changing a single variable in the docs.
But, if you read the article, the reasons given for rust in particular are reasonable, and not matched by assembly or machine code.
It might be the opposite. Python apps still get written despite the performance hit, because understandability matters more than raw performance in many cases. Now that we’re all code reviewers, that quality should matter more, not less. Programmer time is still more expensive than machine time in many cases.
Are Python apps really so easy to understand? I seriously disagree with this idea given how much magic goes behind nearly every line of Python. Especially if you veer off the happy path. I certainly am no fan of C but from a certain point of view it’s much easier to understand what’s going on in C.
The 'magic' in Python means that skilled developers can write libraries that work at the appropriate level of abstraction, so they are a joy to use.
Conversely, it also means that a junior dev, or an LLM pretending to be a junior dev, can write insane things that are nearly impossible to use correctly.
> 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…
Did I get that right or did I miss anything?
It might be the opposite. Python apps still get written despite the performance hit, because understandability matters more than raw performance in many cases. Now that we’re all code reviewers, that quality should matter more, not less. Programmer time is still more expensive than machine time in many cases.
I've cooled significantly on Python now that there are a number of strongly typed languages out there that have also gotten rid of the boilerplate of languages Python used to compete with. Readability gets destroyed when a function can accept 3 different types, all named the same thing, with magic strings acting as enums, and you just have to hope all the cases are well documented.
And the other problem with functions accepting dynamic types is that your function might only in reality handle one type, it still has to defensively handle when someone passes it things that will cause an error.
All the dynamic typing really did is move the cognitive load from the caller to the called.
Why stop at a systems language? Why not assembly? Hell why not raw machine code? You have to rewrite it for every new processor? Big deal. Llm magic means that cost isn't an issue and a rewrite is just changing a single variable in the docs.
Why stop at a systems language? Why not assembly? Hell why not raw machine code? You have to rewrite it for every new processor? Big deal. Llm magic means that cost isn't an issue and a rewrite is just changing a single variable in the docs.
You might wonder that if you just read the headline. But, if you read the article, the reasons given for rust in particular are reasonable, and not matched by assembly or machine code.
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…
I'm surprised the author of this article thinks Go is a "system language". Go uses GC, and therefore can't be used for hard real time applications. That's disqualifying as I understand it. C, C++, Rust, Ada, and Mojo are true system languages IMO. It is true that as long as you can pre-allocate your data structures, and disable GC at runtime, that GC-enabled languages can be used. However, many of them rely on GC in…
Also, despite GC there’s a sizeable amount of systems programming already done in Go and proven in production.
Given how much importance is being deservedly given to memory safety, Go should be a top candidate as a memory safe language that is also easier to be productive with.
> 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.