lolinder

Porkbun has been good to me and a lot of others.

Dependency injection provides the same hermetic-testing capability, so that's not really an answer to OP's question. Effect-as-world-model is, in this specific way, just a special argument slot that only accepts dependency-injected functions.

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 failing to distinguish between token count spent and context window used.

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.

Not just effects, multi-shot effects:

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

Looking at the official description of a Forward Deployed Engineer I'm uncertain what even the nominal difference between this and a Solutions Architect is.

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

Depends on what you mean by better.

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.

I'd honestly be careful with squarespace. They are owned by private equity, advertise on countless YouTube channels, and at the same time their core market is under a looming threat from the AI companies.

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

Their prices had already been going up for a few years before that, which finally pushed me off them starting around August of last year. I'm about to swap my final few domains over this month before they renew.

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

The weird twist here is that I've found that there are times where Fable is actually worse than Opus at a straightforward task, not just more expensive. It'll launch off into its own little world for an extended thinking, then start editing files, and I'll already have spent $5 in tokens before I see enough response to know that it's on the wrong track.

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

This piece focuses on the cost differences from the tokenizer, which do matter, but I wish they emphasized more that even adding the tokenizer to your calculation doesn't provide you with a good way to calculate cost for agentic coding tasks.

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.

Because what they did say is true for both agents and humans. Which makes it a more compelling argument than just emphasizing the specific aspect of that limitation agentic workflows.

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.

You realize that what you're describing is inherent complexity in memory management? This is not something that you can dodge by using Zig, it's just part of the domain.

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.

That's only the correct abstraction if you intended to hold off on releasing the rewrite until you were completely finished, because there's no universe where Bun of all projects releases a production version that uses clone and copy liberally.

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.