nchie

Going all in on Rust doesn't have to mean you'll rewrite everyone's firmware drivers in Rust, nor does it mean rewriting everyone's OS in Rust or rewriting the platform on which Rust is compiling.

I've (more or less; I've read quite a bit of the code) vibecoded several houndred thousand lines of Rust and I've not seen this happen a single time. It sounds like something it'd do when you ask it to "write a linked list while satisfying the borrow checker". Are you sure you haven't (possibly unknowingly) been giving it instructions which ended up luring it into doing these things?

In my experience, when that happens it's most likely because you drew the wrong boundaries. Iterating on the boundaries also becomes quite cheap when developing this way though, you should never expect to get them right the first time unless it's a very common problem you're solving _or_ you've done it before.

For my side project where uptime doesn't really matter but the codebase is quite huge (gamedev of a multiplayer game with Bevy, so both server code, game code, content build pipeline, as well as a TON of editor and authoring code, probably 150k+ LoC), I've been moving towards just reviewing boundaries between modules, APIs, and schemas, and I'm pushing towards keeping things as modular as possible. If something ends up wrong, it going to be isolated and it doesn't infect the rest of the codebase. Every now and then I zoom into a module and tidy it up (or even rewrite it).

I wouldn't dare doing this "carelessly" for anything where people other than me actually depend on it, but you can move very fast while doing it and the risks with bad code is quite hedged. Different modules can mature at different rates when it becomes necessary.

Maybe not related to all of what you were saying, but I think this enables scaling without ending up with progress grinding down to a halt due to shitty code.

That honestly sounds like it's more about either the quality of the codebase, or the driver.

I understand that to be the "emergent abilities" which are spoken about. There are correlations in the dataset that are strong enough for it to seem to have an understanding which wasn't obvious it would have from simply "predicting the next word".

>The coding agents got good in November.

Maybe irrelevant to your point, but I'd argue they were really good already in May if one used the right workflow (planning etc.). They've become better, but they're not saving me significantly more time now than they did 12 months ago.

Agreed, async function coloring makes for better structured code because it incentivizes keeping IO code near the edges while having a synchronous core.

I doubt it, the difference between someone slightly inefficient and someone extremely efficient isn't big enough to matter compared to how much they cost in salary.

That doesn't make it not true though. Markdown generally supports HTML (though oftentimes only a subset), and is typically styled using CSS. Using a web view makes complete sense to me.

> But are we really saying that the primary motivation for async/await is performance?

Of course - what else would it be? The whole async trend started because moving away from each http request spawning (or being bound to) an OS thread gave quite extreme improvements in requests/second metrics, didn't it?

I haven't made a ESP32 design, but I recently learnt KiCad and PCB design enough to do a RP235x board with a non-reference design choice (1.8v VDDIO). I only used the official hardware guide + LLMs for questions, and had it work on the first try - it wasn't too hard!

But dependencies are part of a website? It literally says "Still here when the internet isn't." - but I can't go on there without an internet connection?

I use Claude for work and Codex for private use due to already having a Plus subscription.

I can't say that I have noticed that 5.3-Codex is much better, but it's definitely on par with Opus 4.6, and its limits for $25/months is comparable to Max x5 at 1/4th of the cost (not to mention pay-per-token which we use at work). Claude Code is generally a much better experience though.

Bandwidth doesn't tell us about how many clock cycles it's waiting for the data though (latency), does it?

For example with paging, I don't think those bandwidths make much difference and it's instead the latency which matters. Or am I wrong?