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.

▲

rankdiff 6 hours ago | parent | next [-]

why even write the code?? just tell AI to give output directly!

▲

zephen 6 hours ago | parent | prev [-]

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.

▲

noosphr 6 hours ago | parent [-]

If you read the article you'd know they were talking about go/rust. We can sprinkle bugs with borrow checker to burn them in Rust, fair enough everyone knows that the only bugs that happen in system languages are memory errors. But what's the holy water we can use to banish bugs in Go?

	▲	zephen 2 hours ago \| parent [-]
		Obviously there's no holy water when it comes to go and concurrency bugs. But go is memory managed and statically typed, and, obviously, assembly language or pure binary opcodes aren't. The article certainly isn't perfect, but the thesis wasn't just that "Hey, LLMs can now write stuff for us in more efficient languages." It was (rightly or wrongly) that LLMs can let us more easily use more complicated languages that both go faster and do more checking than most dynamic languages.