What effects provide beyond DI is entirely in their ability to abort (resume zero times) or (in the case of multi-shot effects) resume multiple times. An effect that resumes exactly once is structurally the same as a dependency injected lambda.

You're correct that the former is not a concern for Anthropic, but it's also not the problem I'm pointing out.

The actual is not token count, it's context window. Your context window is finite, and every token you add to it reduces the model's accuracy during inference.

> Algebraic effects with deep, multi-shot handlers. A handler can resume a computation zero, one, or many times, which is what makes exhaustive search and exact inference ordinary library code.

I love me some algebraic effects, but this sets off alarm bells for me.

Multi-shot effects are neat and powerful but are incredibly difficult to reason about for humans, and given that there are few languages that have implemented them (and they're so niche with very little training data) I'm skeptical that LLMs are sufficiently better at them to make up the gap.

One-shot effects are a cross between `throw` and a function call. Multi-shot are full-on delimited continuations and come with all the complexity that entails.

Is the nominal difference between an archetypal FDE and an archetypal SA greater than the difference in the SA role from company to company?

I chose Porkbun because it's a small company with good prices, a good vibe, and all the tools that I need. Cloudflare was never going to be on the table because I don't want to feed the beast that is already swallowing the entire internet.

You need your domain registrar to be stable and predictable. Their profile is not that.

Porkbun has been great so far. Easy to use, refreshingly minimal, and good prices.

Opus's verbosity is actually a boon sometimes for catching false starts early.

Other traits where models differ that have an even greater impact on your total spend:

* How much context do they load in to solve a given task?

* How long do they spend thinking to get equivalent results?

* How many times do they stop and ask you for input, and are you there to respond to them before the cache runs out?

* Etc.

Incorporating the tokenizer just makes a very imprecise measurement of cost a little bit more precise, but in my own experience I have not found that the token cost is a significant driver of task cost whether or not you incorporate the tokenizer. Everything else about the model's behavior has a much larger impact.

In one comment you are presuming that agents can just ignore ergonomic problems, which would be a kind of magic if it were true, and in the next you are saying that their inability to digest enormous quantities of unnecessary tokens is some kind of flaw that needs to be called out.

Enormous quantities of unnecessary tokens are bad ergonomics for anyone, agent or otherwise.

The difference is that in Rust you get strong guarantees for everything that is not inside of unsafe and clearly demarcated areas where things might go wrong. Even if you never eliminate a single unsafe block, the clear demarcation is valuable as an artifact in its own right.

Unsafe in theory in a transliteration is only as unsafe as the original Zig was, which makes it a perfectly reasonable place to land as a transition point in a way that introducing large numbers of allocations simply isn't.

> And that is considering humans write the code manually. Why does it matter if agents write the code? This makes no sense.

Because the particular form of non-ergonomic code that is demonstrated here amounts to a quadrupling of tokens. That's a substantial hit to the context window for safety that isn't even statically enforced.

You can argue that that's a bad justification for not doing it, but that's a debate on the technical merits, not a claim that they didn't provide justification.

It's also outside the scope of the project if they're using Webkit's engine for that part. Which means Bun itself isn't a JIT, it's all the stuff built around the Webkit JIT, so whether or not Rust is useful for the JIT is entirely immaterial to the question of if Bun would benefit from Rust.