rstuart4133

> bonus points if they create a comprehensive test suite first.

If they didn't have a very comprehensive test suite at the end of the exercise, then based on my experience someone is kidding themselves.

A friend had a tiny accounting system - maybe 15k loc, written in a combination of Python 2.7 / bash / LaTeX. I migrated it to Python 3.13 or whatever by hand. I did try using an LLM for that, but it did things like delete chunks of functionality so I had to check every bloody line it changed. Translating Python 2 to 3 is a fairly mechanical process, so traditional tooling worked better. Then I thought I'd explore LLMs by getting one to translate it to Rust.

The original had no tests or doco. As others have noted, the first attempt superficially looked identical to the original near immediately. You think "Wow". But in my case, it was riddled with bugs. When I asked it to fix bugs I noticed, it introduced as many bugs as it fixed.

I eventually figured out the limited context meant it kept forgetting all the lessons it learned when it fixed things, so it reintroduced old bugs and misunderstandings fixed earlier. (Like I said, this was a learning exercise.) Which is how I came to the same realisation a lot of the industry has - the solution to the context problem is you have to define the application via tests, then tell it to make the tests pass.

The tests rapidly became huge and unwieldy, so part of the exercise became DRY'ing the test code out by getting the LLM to build an integration test harness. The harness captured UI responses, files written, emails and printer output; froze time; fed in known input; and compared the outputs with results captured from the original program.

That cured the bug injection problem, but there were still bugs in all sorts of unexpected places. By unexpected I mean places I would be surprised to find them in human-written code. Human devs run the program in the same way human users do. They use the backspace key and the browser back button to navigate as they test their work. AIs don't. They will use APIs to inject test data unless you explicitly tell them to do it differently. The size of the tests exploded to be far, far larger than the code. Rather than coding I spent my time testing, telling the LLM to write tests to catch the errors I found, then writing standing prompts to try and prevent similar errors. It was meant to be a vibe-coded project, but in the end I got worried about code paths I suspected existed, so I looked at the code anyway to see if they were written the wrong way. Sometimes they would have blown up, say when the SMTP server was offline. To be fair, there was no need to look - I could have just asked the LLM. How a programmer without decades of experience would know what to ask is a mystery.

There is no doubt I got a working Rust program faster than if I had written it myself. Several times faster - but not orders of magnitude. If it was a program I had written, so I was very familiar with it, and it had excellent doco, and a high-coverage test suite, it probably would have been orders of magnitude faster. I think Bun's Rust migration might be an example of that - it's a best-case scenario. There were lots of early announcements, but it took over 6 weeks before they were confident enough to ship it in Claude Code.

But an "I migrated a program with hundreds of thousands of lines of code to a new language and ended up with production-ready code in a few days" - sorry, pics or it didn't happen.

That was interesting.

Minor spoiler: looks like the platforms found a way to mass produce the formula Robby Lefkowitz made money out of, to everyone else's detriment.

In Australia are have organisations with titles like "Independent Commission Against Corruption". Their remit is to investigate political corruption and corruption in the public service (like say the police). They come in two flavours. In some states their deliberations are done in public. In other states they are secret.

Over time it's become evident open model is far, far more effective at ensuring the public has confidence the people running the place are doing the right thing. It does risk the occasional unwarranted "witch hunt". But that threat ensures powerful people avoid doing things that while above board, could arouse public suspicion. Less suspicious acts mean higher trust in the government.

Is there more to this than the Wikipedia article says?

While it does say:

> Gilmore also complained about being subject to "secret law", when the airlines and government refused to show the directive under which they were requesting ID.

nowhere does the article say the courts commented on the complaint, let alone ruled on it.

Nor does the article say anything about "Ignorance of the law is no defense when you are charged with violating a law". The reason given was instead:

> there was no constitutional violation because air passengers could still travel without identification if they instead underwent the more stringent "secondary screening" search.

I'm not saying your wrong, just that the article you offered as evidence doesn't go as far as your claims.

> These "wrapping" keys were not "weaker". They were completely unfit for purpose.

Oh come on. They clearly didn't intend to use 4 as a private key or to wrap it. They had just purchased millions of dollars of HSM's to store them. It was something more subtle than that.

Have a little imagination. The transfer procedure sounds bespoke - possibly just a shell script using openssl to encrypt things at one end, and decrypt them at the other. Let the man who has written 100 shell scripts without a bug in one cast the first stone.

But not so subtle that good software engineering procedures wouldn't have picked it up. In fact today just an LLM review of the shell script probably would have caught it. The Internet Death Sentence was warranted - because poor software engineering procedures are unforgivable in a CA. But those procedures and policies aren't easy or cheap to come by. If they were just "don't chose 4 as a primary key" my grandkids could do it.

Within a decade. Starlink had little competition, and the world had little reason to build one - it's a good service and the price isn't bad.

Now Russia, China, Japan and the EU are all building competitors. Most of SpaceX's revenue comes from Starlink launches.

True, but I would have been surprised if that wasn't the case. The reason line looked wrong to me is the lifetime of Some(l) was shorter than the type declaration wanted. The simplest explanation for the bug is compiler wasn't checking the lifetime at all, and the link you provided seems to confirm that is the case.

If that's true it's not a very complex or subtle bug. The very first response of "How on earth was this not found before this???" seems entirely appropriate to me.

> however the ability to leak memory is pretty demonstrable

It is, but safe Rust merely makes it hard to do by accident. Leaking is not "memory unsafe" because is does not currupt anything, so it's legal.

> This bug however is quite dangerous, because unlike many soundness bugs it seems plausible to hit by mistake.

Possibly. I'm no rust expert, so I had the read the code slowly, building up a mental model of the types being used. For me, the effort that required is one of the more painful aspects of Rust.

Nonetheless when I got to this line, I stopped reading:

    q.0 = Some(&l);

Given the type declarations it's "obvious" it should not compile as it directly contradicts the types 'static lifetime. You don't deliberately write code that doesn't compile.

I write lots of code that doesn't compile of course. It's perfectly safe because the compiler catches it. Right now, I feel like a climber at the top of a mountain who just discovered he forgot to attach his safety harness.

Who knows. Maybe all of crates.io will compile with the fixed compiler, because this is a mistake humans or LLM's never make. We will see.

I read it, but I didn't agree with it. Over decades Utrecht drifted from small town, to large freeways running through the middle, to flooding the freeways to create canals. And now converting freeways to long parks.

Over a long time period like that it's never that you can't do it. The USA and Canada managed the conversion from European style cities before trains, to public transport based cities when trains and trams arrived, to car centric easily enough. They could go back.

If they don't, it will be because the won't, not because they can't. I wouldn't say never, because once the car manufacturing falls away a major source of lobbying pressure will fall away. Car centric lifestyle needs a champion, because it's more expensive, less efficient time wise, and less healthy than the alternatives.

There is no car manufacturing done in the Netherlands now. I doubt this is a coincidence.