This completely ignores the fact that such a language might be more difficult to master because it uses fewer higher abstractions; CPU efficient languages tend to be closer to the machine domain and further away from the mathematical and real world. So while in theory the language lets you write very efficient code, you might well miss the opportunity and it could even be that using some off the shelve abstraction in a higher level language, your code would have been more efficient.

To drive that point to the extreme: the ultimate CPU efficient language is the language of the CPU itself: assembly. Try writing an efficient highly scalable webserver in assembly alone, good luck with that.

Then there is something else that all these articles conveniently ignore: development speed. Most of us write software for commercial enterprises. Product owners want the new feature tomorrow, not next year. They don't want a clever and amazingly fast application that might crash in production, they don't want security holes by missed buffer overflows.

Also, most of us work in a team where colleagues come and go, including yourself. Your colleagues won't be happy with you when you leave them some amazingly cleverly and efficiently written software that nobody understands or can maintain.

TL;DR; while all else being equal, the point of the article is true: it has little to no meaning in the real world. Yet, with phrasing like 'green languages', 'reduce the carbon footprint', these articles will catch on to an uninformed audience again and again.

If it is, and it works well, then to me this is far more meaningful than the fact that AI wrote 130K lines of code.

- you are using AI as an E2E testing tool and it's a requirement to not just test the API but also the workings of the UI

- you are using some third party tool and want to automate its usage

This has been tried so many times already. It works nice for functions that only do some arithmetic. But in any real life system that pushes data around over the network or to databases, most things will happen inside effects which leaves the compiler clueless as to whether the function implementation does what it's supposed to do or not.

Don't get me wrong, I'm a big fan of using the compiler to improve productivity and I also believe strong typing leverages LLM power. But this kind of function specification is a dead end IMO.

> The trap is that get_user_by_name ends up loading shared libraries from the new root filesystem to resolve the username. An attacker who can plant a file in the chroot gets to run code as uid 0.

To me such a get_user_by_name function is like a booby trap, an accident that is waiting to happen. You need to have user data, you have this get_user_by_name function, and then it goes and starts loading shared libraries. This smells like mixing of concerns to me. I'd say, either split getting the user data and loading any shared libraries in two separate functions, or somehow make it clear in the function name what it is doing.

Well this is true, but that doesn't mean that there isn't any other way to acquire this knowledge. Until now, this way of gaining deeper understanding was simply the most practical one, since you needed to write lots of code when starting out as a software engineer.

But it's just as well possible to gain knowledge about useful abstractions and clean code by using AI to do the work. You'll find out after a while which codebases get you stuck and which code abstractions leverage your AI because it needs fewer tokens to read and extend your codebase.

- a very large codebase

- a codebase which is not modularized into cohesive parts

- niche languages or frameworks

- overly 'clever' code