CamouflagedKiwi

I generally like `encoding/json/v2` and I'm glad they did it.

I wish they'd left `MarshalIndent` in there though. The equivalent code is super complicated and non-obvious, so it's a pain to migrate, and it's a pain when you're banging out some quick code and want to dump some readable JSON. I suppose these days the LLMs can write the complicated version for us, of course.

This feels like it should ideally be something public in the structs package so anyone can leverage it, not just a specially blessed internal thing for the sync package.

It's absolutely not for these models. There are plenty of consumer GPUs out there with 8 or 12GB VRAM - they are comparatively very fast at inference but just aren't big enough to run lots of the models you want. Also context management is a massive pain.

Bit dubious about how some of this hangs together. One detail that stood out to me:

> 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.

I think pretty unlikely: there is enough pub density that it's unlikely that removing that requirement nets 10 minutes of saved journey time from all the furthest destinations.

Probably because they don't want to self-host Windows or MacOS servers when they can pay someone else to do that for them (or Linux ones, I assume that is within their wheelhouse for production but CI is a bit of a different beast to model inference).

Their policy doesn't cover upstream, it's only for the Gentoo project specifically. It's clearly infeasible for them (or Debian) to try to control what their upstreams do, especially with the kernel accepting LLM contributions now.

Interesting article, seems more balanced than Andrew Kelley's one that it links to.

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.

They don't really "just get to say" that. Declaring yourself bankrupt is a fairly major thing that will have long-term consequences. It clearly isn't desirable to do casually, we don't see it often (at least not in the personal sense; businesses can be a bit different).

> 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.

You can't really tell people that they just can't be bankrupt though. What are they supposed to do if they have debts they can't pay but they're not allowed to declare bankruptcy because they pinky swore they wouldn't do it seven years ago?

Alpha Centauri was such a fantastic game. And even though it encourages you to move forward with technology, the tone has this unease about what you're doing. There's a lot to be learned from it.

I don't know anything about Adobe's model - I have (pretty happily) never bought anything from that company. But the two are not very similar, and I don't buy the argument that you're trying to make - I think you're trying to bring in dislike of Adobe's model as an argument against Epic's, despite the two being pretty fundamentally different.

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

> What do you even mean by "works", specifically?

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.

Sure, and then he can afford it, because he's making over $1M/year revenue on this sim, and taking a very reasonable 5% off the top of that. So it blunts the profits a bit at that point, but it hardly seems like such a terrible thing at that point.

Because you know that the current one works. If you have a bank running on COBOL (or whatever), you've had that for 30+ years now, so while it might have bugs, you know what they are. You don't know what the LLM output is. Hence back to my original point: writing the code is not the hard bit. Making yourself (and your CEO etc) comfortable to put that into production is one of the hard bits.

> its hard to evaluate how much trust can be put in a project of this complexity at this early stage.

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 misunderstand.

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.

I would certainly vote for Vimes if he stood.

Surely better than this engineer having to pay $100k upfront which would likely mean he never made the game at all. 5% over a million seems pretty reasonable to me. I guess it'd be an issue if profit margins were thin, but that wouldn't be the case here.

I have some familiarity with the bank situation, and while a lot of them are on some very old systems (maybe COBOL, maybe something else, either way they want off it) the cost of actually re-writing the code is far from the most significant issue.

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.

Yeah I was thinking exactly this. Also I don't think it can reach my dryer.

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.

Nice find.

Can't help but feel this is one of the subtle traps hidden beneath the advice that contexts aren't supposed to be stored. I know it's not always that easy, of course.

Right but as they mentioned, at least then they are communicating with a human about it, not going back and forth with a machine which they clearly do not enjoy.

Sure, that's only made worse by the suggestion here to not install any version of it at all.

Not quite accomplished, if it's creating text on the pull requests that looks sufficiently human-like, but you're still worried about the quality of the code and that the submitter doesn't understand it.

It's also kind of pointless. Almost immediately, something will be installed that will require installing the .NET runtime, maybe multiple versions of it.

If the argument is to try to prohibit it, then it just won't work as a platform, because too much existing software won't work on it. There's a lot of garbage I'd love to not have (all the stupid hardware config apps all the manufacturers push on you) but just having that functionality not work can't be the answer.

I like the idea, but I don't really see why this would change the 'Builder' population. Gamers would love it (I have a Windows 10 install around for gaming, I'd take this in a flash, I'd probably not even complain too much about the money), but that isn't the same. To make it work for builders it needs to be an attractive place to do development and I don't see how this really helps with that (other than maybe improving the audience for their products). Although I am speculating there - I haven't written any code on Windows for maybe 15 years now and I don't expect ever to do so again.

I wouldn't describe the 2019 final as infamous? Other than us all sitting around shouting "What on earth is a super over?" I don't remember it being very controversial. It was certainly a pretty exciting finish.

It's pretty much completely not like playing the game, because the batting team can't meaningfully hit the ball.

Right, so it's some JS SPA thing as well (of course).

Out of interest, do you not often find this a problem these days? I feel like there'd be a lot of sites out there that are non-functional or literally do nothing without JS.