lunar_mycroft

I agree that arenas aren't always the best choice, but I think you're underestimating how often they are. Not only does a lot of software have elements that are well suited to arenas (request handling for web servers, frames for games and UI, etc), but a lot of allocations are for short lived intermediary values anyway (the stack is basically an arena with a bit less flexibility).

(Also, you do not need to sell me on bumpalo, I use it heavily already)

Disclaimer at the start: Rust is my favorite language, this very much isn't an attack on Rust.

> Dropping vecs that contain strings does not make any Rust code in the real world slow. You would need to have a vec containing billions of strings, occupying several gigs of memory

I actually had a hobby project where that became very noticeable/too slow for my requirements at around 800k Strings, so several orders of magnitude less than your estimate. Switching to a solution that freed all the memory at once predictably made it run effectively instantly.

> And for extreme cases like that, you can simply use arenas

I think this is a fundamentally flawed way of thinking about things. Yes, each individual string allocation and drop isn't going to cost much, but in combinations with all the other similar decisions you're likely making if you think this way, plus the decisions of library authors, etc, it can add up even if strings specifically aren't a major problem. Avoiding pessimization by default instead of only when you can't ignore them any more is a good habit to be in.

You aren't paying API prices. Anthropic (or OpenAI, SpaceX, etc) are almost certainly losing money on your subscription. How long they'll be able to continue to subsidize your usage is an open question, but they definitely won't be able to do it with everyone (currently, their solution is to make enterprise users pay per token, but that might change). What that means is that for the customers that the frontier labs need to be profitable, going with a closed weight provider isn't "marginally better intelligence for marginally higher (or even lower) prices" but "marginally better intelligence for much higher prices".

(Going from memory here)

No, it's possible that there's a single gene that would do it, meaning a single mutation would enable it. But that's not what happened here. Instead, there were multiple genes involved, with some of the necessary mutations occurring long before the other.

We've had a long discussion only because you refuse to admit that a very simple solution would work (despite completely failing to show how it wouldn't). The problem is that your opinion is not in fact proof that you're right.

First, GP's proposal already addresses that. If both are present, CLAUDE.md would be used. Second, that is solved with a settings toggle. Read a boolean from .claude/settings.json and disable the new behavior if it's true (or false, depending on what you want to name the setting). third, you skipped the second part of my question: "how would implementing it the way Anthropic did address that?" Implementing the same behavior through multiple layers of abstraction and an order of magnitude more code doesn't solve the issue you mentioned.

Bonus forth point: why is this critical to solve for claude code, but not for all the other harnesses which have all converged on AGENTS.md for this purpose?

How, exactly, would the proposed solution (combined with a setting to disable it) break, and how would implementing it the way Anthropic did address that? Be specific.

Just saw this now. The two aren't remotely in conflict. The _rewrite_ (from zig to rust) almost certainly didn't result in the performance improvements they're claiming, because rust and Zig are roughly equivalent in that regard. We know that they included other changes with the 1.4 release (in other words, 1.4 is not just 1.3, but in rust this time), so it's far more likely that those changes are responsible, not the rewrite.

1. Ironically enough, I (GP) am a software developer.

2. How exactly do our jobs depend on a thing which has been around for far less time?

At this point, I find myself hoping for a AI triggered mass casualty event that's not at a civilization destroying level, because that seems like the only thing that might actually stop these people from driving our entire species off a cliff before it's too late (edit: besides running into some natural obstetrical that stops them from developing a powerful enough model).

The announcement also makes it very clear that 1.4 isn't just a rust port of 1.3. Rust is my favorite language and it can be a bit faster than other systems languages in the right circumstances (because the compiler can make optimizations based on assumptions that wouldn't hold without the borrow checker), but numbers like those seem far more likely to be the result of other changes than the language shift.

> We've normalized science fiction. Go back 5-10 years and ask anyone whether we'd soon have something like LLMs.

LLMs are incredibly impressive. It just doesn't follow from that that they're capable of all the things proponents claim they are.

> I just can't believe that LLM haters really like computers or technology

In a lot of ways the reverse is true. The LLM coding ecosystem seems designed by people who are unaware or actively despise the fact that they have access to a computer, and almost the entire point of LLMs is to make interacting with computers less like interacting with computers and more like interacting with people.

> If you actually used LLMs instead of preaching against them from the sidelines with no real experience, you'd know such statements are wrong.

What about the people who do have a lot of LLM experience and agree with OP?

> That thing cannot do the stuff you say it can. And there is no way I will ever try it. But I know for sure I am right.

If someone claims to be able to fly by strapping bird wing shaped pieces of plywood with feathers glued on to their arms, do you need to personally jump off a tower with them to say they don't work, or can you look at the results of others attempting it and draw conclusions based on that? LLM proponents are making claims about their capabilities which can relatively easily be checked without using LLMs yourself. To pick an example where LLM proponents are correct, anyone who says LLMs can't generate syntactically valid code can be proven wrong fairly easily by producing an example of syntactically valid, LLM generated code.

Further, if you read the rest of the paragraph you responded to, it's clear that this claim is about the state of the industry as a whole. "Software has not improved in quality, got faster, become cheaper to produce (when you exclude the mountain of poor-quality demoware that no reputable organisation would touch with a barge pole), or become more capable." Whether this is true or not is something that can be evaluated without ever having prompted yourself, or even arguably without being a developer at all.

Do you think the LLM reads every page on the internet before generating your answer? Of course not. What happens is that it use some sort of ranking algorithm to pick the pages that are most likely to answer your query and reads *them* (at best. At worst it just makes something up). You aren't avoiding the problems with ranking algorithms by asking an LLM, you're taking all of those problems, adding more problems on top, and pretending that this is somehow better.