> They removed mounting screws, disconnected the servers and put them in laundry bags — 20 bags in all, each large enough to hold four or five servers.

That's like 100kg or more of servers in each bag? I guess that is not totally impossible but it doesn't seem like a particularly easy way to move them around. It's not like putting five laptops in a bag and walking out with it over your shoulder.

The thing I still think is wrong: why are Anthropic rewriting a Javascript runtime from Zig to Rust? Why not rewrite Claude Code itself in Rust (or Go or whatever, lots of options there) and drop Bun completely. That actually seems like an easier solution (rather than having to create a performant, correct Javascript runtime, just rewrite your CLI console app in something else) and the final result is better (smaller and faster) although likely not on the most critical axes for them.

> It's one thing if you're in a crazy desperate situation and someone takes advantage of you

In that kind of situation, declaring bankruptcy is likely not going to help you so much. Those people are going to come after you anyway.

I think you sort of fundamentally misunderstand this. Bankruptcy isn't thievery - it's a solution for people who get themselves into a bad situation and don't have a way forward. Say you bought a house with a mortgage, the value of the house has now dropped for some reason so you have negative equity, and you lose your job and can't afford to make the repayments any more. What should happen? You don't have money to pay what you owe, and you can't get it because your total net worth is negative. Saying that's theft doesn't help the question of what to do - society doesn't benefit from dumping on that poor person any more.

"it's not all rainbows" - I would also not let perfect be the enemy of the good here.

It runs and accepts people's payments, which means you're not on the front page of the newspaper (not in a good way).

> ... because they're stored in terrible ancient mainframe databases, the text fields all have tiny maximum lengths. Hence they're all abbreviations. Attacker-controlled abbreviations without any authenticity assurance of any kind!

They also have to go through payment networks which are very often the limits on those things. So yeah, it sucks, but just fixing one DB isn't enough - the whole thing has to get upgraded.

> I have no idea who actually transfers money out of my accounts! There are no URLs, no metadata, nothing to actually confirm the identity of the other party. Every field in a transaction record is 100% attacker-controlled and unverified by my bank.

There is a little bit, but not much. Again, if these transfers are happening via card, it's all a terrible old fixed-length setup. Would be great if it was better, but you need Visa and Mastercard to upgrade as well. And of course there _is_ verification - most banks don't do a great job of surfacing this but they know if they've verified a PIN or CVC, or if it was contactless (in which case it _is_ unverified, but society realised we prefer the convenience there).

> Use cryptography. No, not crypto coins! I just mean a bog-standard algorithms like public-private key signing so that it is possible to confirm the source of transactions.

Obvious question then: You've made a card transaction. It is signed with the other party's private key. What does that buy you? How do you attach trust to this key? Whose is it - the payment gateway or the merchant?

> I would much rather have something generated with the assistance of a modern LLM than what we have now, which is security holes big enough to drive a panamax container ship through.

Sure, and if the LLM can rewrite enough of this system to get what you want, there's heaps of room for improvement. But this is orders of magnitude bigger in scope than rewriting your one old bit of COBOL software, it's systematic.

I don't know, I'm not finding it hard to evaluate that at all.

I've had bad enough experiences with gevent in the (now fairly distant) past, and that's a well-established project, just a subtle one with a large blast radius. This has all of those problems, plus is _much_ larger and I don't think can possibly have been tested as widely as I would want. I get maybe there's a lot of test code, but I think this kind of thing you only really know when the rubber meets the road.

You could run one of these things on a mainframe, because it's a zero-downtime machine - you can swap out parts of them as they run. But fundamentally it's a singleton. It is deeply naive to believe you can trivially translate that to something running on Kubernetes just "because Rust".

Of course most companies that need distribution do manage to do that, and eventually the banks will get there too. But it isn't feasible to do that by translating their existing non-distributed COBOL code, they need a fundamental re-architecture, and that is much harder.

Consider: You have a big mainframe running your tier 1 bank. Assume that you can see all the code on it, and you can feed all that to an LLM if you like. Getting it to spit out a Rust version is not what you actually want - you now have a modern language but it's still a singleton instance, so where do you run it? Most hardware doesn't give you enough uptime for what you need here, because what you actually needed was a re-architecture for distribution / failover / whatever, and while you could ask your LLM to do that you aren't going to run your bank on the result.

I am happy this kind of thing is being worked on, I just don't think this is gonna be it - they really talk around what it does but "folding clothes" isn't enough. $8k to handle a complete laundry cycle (including ironing) might be interesting.