Code is primarily to communicate from human-to-human, and only incidentally for computers to execute

Uhm what? No. That is a stupid thing to say. It is primarily intended for computers to execute, but in a way that humans can understand.

And 1 million lines to truly review. Reviewers are used to their own heuristics based on common and critical mistakes to find errors. I reckon AI errors won’t follow familair patterns, making reviews even more tedious.

Works is a relative term

Assuming a full-time employer engineer works 20 days a month, that’s 50,000 lines of code a day.

Assuming an 8 hour work day, that’s 6,250 lines of code per hour, or 104 lines of code per minute.

This is humanly impossible without using AI and automation at every stage of the process. Good luck with that.

I’m guessing where we’re headed is software “engineers” becoming AI prompt “engineers” for design, development, review, testing, and shipping.

Buckle up, shit’s gonna get wild.

I mean, I don’t see the issue.

Producing such amounts of code with AI should be a easy as pie.

Obviously, through many outages and bugs present in the Windows and other Microsoft products, they could not give two shits about quality. And quantity is easily measured and also achieved with the Enormous Bullshit Spewer.

I always wished for Microsoft to die, and if this is the way, I will clap for their efforts.

This is how you invent new classes of vulnerabilities

I can’t believe this is real 😂

LMAO they actually said that 🤣🤣🤣

The rust part, if done well, would be a good step.

We’re talking machine translating the whole codebase from c to rust like one would translate a book from one language to another, here (i.e., without the machine actually understanding a single word, much less long groups of them).

The result will basically be something like this:

unsafe {
 //insert the entire codebase here,
 //mangled beyond recognition
}

Indeed.

In some ways, this kind of thing is ideal for Rust. It’s at it best when you’ve a good idea of what your data looks like, and you know where it’s coming from and going to, and what you really want is a clean implementation that you know has no mistakes. Reimplementing ‘core code’ that hasn’t changed much in twenty years to get rid of any foolish overflows or use-after-free bugs is perfect for it.

Using Rust for exploratory coding, or when the requirements keep changing? I think you’ve picked the wrong tool for the job. Invalidate a major assumption and have to rewrite the whole damn thing. And like you say; an important choice for big projects as choosing a tool that a lot of people will be able to use. And Window is very big.

They’re smoking crack, anyway. A million lines per dev per month? When I’m doing major refactoring, a couple thousand lines per week in the same language, mostly moving existing stuff into a new home, is a substantial change. Three orders of magnitude more with a major language conversion? Get out of here.

I mean, Rust has the massive upsite that it won’t compile in many cases if you fuck things up. Then again, embedded or generally low-level driver-y stuff is still in its infancy in Rust. Relative to C/C++ that is.

There is stuff that you need that has no official Rust support. There is poor documentation and half baked frameworks. There are examples being silently outdated, breaking changes between framework versions, and nighlty-versions from Github mixed in to fix them. And then of course plenty of timing and hardware dependent things you will need to do yourself.

I do this for a living and personally tried to use AI here and there to help me out, but oftentimes it fails miserably. Not always, but very often.