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.

The example shows three extra lines of code, two of which are `defer`s. I'm not an expert in Zig and can't tell you whether the example they give is contrived, but the claim they're making is way more than "a wrapper type".

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.

Because if you have to quadruple the number of tokens in your code base in order to make the Zig provably safe, you have 1/4 of the context window to do useful work.

No one's obliged to respond to hearsay by trying to guess what the other party might have misheard to arrive at a false conclusion. It's enough to demonstrate that the conclusion they came to was false, and if the other party would like to defend themselves they're welcome to explain why they came to that misunderstanding.

If that's what he meant that doesn't speak well for his communication in this post, because "the Bun team told us that they were not fuzzing anything" is a wildly different claim than "the Bun team told us they weren't using a specific tool for fuzzing".

The very next sentence justifies why they didn't do it: it argues that they would have ended up with what was technically Zig but something that was much less ergonomic than what would be expected from Zig.

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.

If the end state were unsafe Rust, you'd be right, but that's explicitly not the intended end state. Unsafe Rust was the reachable first step. Now they have a Rust version and can iteratively remove `unsafe`, which they couldn't do before when it was in Zig.

making sure the JIT doesn't emit anything broken or naughty is completely outside the scope of Rust.

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.

No one involved in the port proposed "blindly porting Zig code 1:1 and calling it a day". From the first blog post the creator said:

We can gradually refactor it to reduce unsafe usage and look more like idiomatic Rust after Bun v1.4 ships.

What the rewrite does is make the unsafe code greppable, which is a necessary first step to eliminating it and one that's actually achievable rather than going straight to idiomatic.

Every successful refractor takes this form of stepwise changes that leave the behavior intact. It just so happens that in this case the first stepwise change was the implementation language.

The discrete number of cows being born is theoretically fine-grained enough to actually respond to 2–3 vegans yielding one fewer cow. It's unlikely on a one-year time scale, but one cow only goes so far.

Even a thousand AI objectors aren't going to limit the demand for a data center, in no small part because these investments are only partially driven by current demand and are significantly driven by expectation of future demand. And they're really not going to lead to smaller data centers either because if you're building a data center in the first place you're going to spec it out for future demand.

Regardless, I think in both cases it's important to be realistic about the actual impact that one person has. If that number is disappointingly small, that serves as signal that your conscientious objection isn't making the industry you're objecting to as uncomfortable as you would like to think. It may still be worth objecting for your own sense of self, or maybe it serves as an invitation to evangelize your position more, but either way there's not much value to measuring things in a way that gives you an illusion of greater impact than you actually have.

Alternatively, they're people who write documents in a field where LaTeX is the standard, they're not computer savvy enough to try to even look for something new that might be acceptable or might compile to LaTeX, and at any rate they want to focus more on their research than they do on changing the typesetting norms in their field.

(No shade on people who do decide to use alternatives, and Typst is great!)

Yes, that too. It was in newspapers hours before the attack, so there's no way Iran didn't know it was coming.

Possibly. It could also be evidence that the bombs didn't really do their job. Either they missed or the bunkers were fortified enough and/or deep enough to avoid even the bunker busters.

Coordinating a botnet to launch a DDoS is commodity software at this point. You could argue that the engineering that went into the coordination software is good, which may or may not be true, but simply launching a botnet is well within the capabilities of a script kiddie and not something that shows sophistication on the part of the attacker.

Like I said: it broke records for data throughput. It doesn't hurt that Cloudflare has an interest in publicizing the size of the DDoS attacks it fights off.

in spite of not having met your arbitrary and personal bar?

I'm not sure what you mean by this. I didn't establish any sort of bar for what sorts of DDoS should get headlines, I'm just agreeing with OP that that line in the article doesn't make any sense. There may be other reasons to believe this attack was well-engineered but the article doesn't get into them.

Not necessarily. It could be one for loop running on tens of thousands of compromised IoT devices, with the only thing distributed being the command that starts the loops.

Right. So why does the fact that they targeted 34,500 ports show it was a well-engineered attack? By itself it's just evidence that they know how to iterate over ports. Coupled with the data size (7.3Tbps) we know they had an enormous botnet. None of this points to a well-engineered attack, it just means that lousy IoT has made botnets incredibly cheap.

A well-engineered attack would not draw headlines for its scale because it would take down its target without breaking any records.

Video games I feel like reverse this general trend, though. Unless they have a major story component (and sometimes even if they do) many games get iteratively 'better' (better for the purposes of making sales if not of making original fans happy) for various reasons: improvements to the core game loop, polish that makes the game more appealing to new audiences, and most importantly graphics.

Story-based content is what struggles with sequels because it's really hard to both capture the feeling of the original sufficiently to satisfy existing fans while also telling a new story that's interesting in its own right. Being derivative without being too derivative.