Rust is not a memory-safe language. Memory safety, as the term has always meant in language design — the property that programs in the language cannot violate memory integrity — is a compositional property of a language and its runtime: it holds for all programs, over all data shapes, unconditionally. Rust does not have this property.
What Rust has is a static checker that verifies an ownership discipline over tree-shaped data only, plus a set of unsafe escape hatches whose use is not optional but structurally mandatory: any cyclic, self-referential, or densely shared data structure — doubly-linked lists, graphs, DOMs, scene graphs, caches, entity systems — is inexpressible under the checker and forces the program into hand-written unsafe, runtime reference counting, or unchecked index schemes. Because these structures dominate real systems software, the unverified surface of a Rust program grows with the program's structural complexity, and at engine scale the observed end state — in Servo, Bevy, and Zed alike — is that every large Rust project builds its own bespoke, unverified object-lifetime runtime.
A language whose safety property is conditional on universally quantified, undischarged proof obligations across its entire ecosystem, whose checker cannot express the core data structures of the domain it targets, and whose flagship projects manage memory through hand-audited runtimes, is not a memory-safe language under any definition of the term that does not also admit reference-counted C++. Garbage-collected platforms are memory safe. Rust is a memory-disciplined language with a memory-safe subset for trees — and the difference is not pedantry; it is the difference between a property of the language and a property of small programs.
If you would like a rigerous look at this reality, read on for the full paper. This is not an attempt to throw shade on Rust developers. Rust has many great properties. People like it. Languages have become popular for less. Memory Safety, or "safety" in general is not one of them, and we should stop pretending it is.
I respect someone who knows what they like, but i love the journey as much or more, and i love AI coding. Not vibe coding mind you, deep engaged, specify tightly and review most edits in a high velocity flow state. Its not easy to read code at 80 tokens/second, but its fun, and feels more like im dreaming in code, using AI to type exactly what i want at 10x the speed. Which allows me to experience more of the journey..and i still get plenty of thorny bugs to work through. What would you code, if you could code anything you dreamed. Go code that today. Btw, 50 years old,started programming at age 9.
THe composable executable tool pattern is great, but hiding all details behind "search" is no panacea. Without any capability description in the context, LLMs won't necessarily know they SHOULD search for something in the tool API... so it's a tradeoff.. The real challenge is figuring out how to give them context-aware tool documenation. Maybe if that's built into the model somehow with a retrained model, or if it knows broadly enough about cloudflare (or any provided sdk)
The news is not that they turned off this account. The news is that this user understands very little about the nature of zero sum context mathematics. The mentioned Claude.md is a totally useless mess. Anthropic is just saving themselves from the token waste of this strategy on a fixed billing rate plan.
If the OP really wants to waste tokens like this, they should use a metered API so they are the one paying for the ineffectiveness, not Anthropic.
(Posted by someone who has Claude Max and yet also uses $1500+ a month of metered rate Claude in Kilo Code)
Rust is not a memory-safe language. Memory safety, as the term has always meant in language design — the property that programs in the language cannot violate memory integrity — is a compositional property of a language and its runtime: it holds for all programs, over all data shapes, unconditionally. Rust does not have this property.
What Rust has is a static checker that verifies an ownership discipline over tree-shaped data only, plus a set of unsafe escape hatches whose use is not optional but structurally mandatory: any cyclic, self-referential, or densely shared data structure — doubly-linked lists, graphs, DOMs, scene graphs, caches, entity systems — is inexpressible under the checker and forces the program into hand-written unsafe, runtime reference counting, or unchecked index schemes. Because these structures dominate real systems software, the unverified surface of a Rust program grows with the program's structural complexity, and at engine scale the observed end state — in Servo, Bevy, and Zed alike — is that every large Rust project builds its own bespoke, unverified object-lifetime runtime.
A language whose safety property is conditional on universally quantified, undischarged proof obligations across its entire ecosystem, whose checker cannot express the core data structures of the domain it targets, and whose flagship projects manage memory through hand-audited runtimes, is not a memory-safe language under any definition of the term that does not also admit reference-counted C++. Garbage-collected platforms are memory safe. Rust is a memory-disciplined language with a memory-safe subset for trees — and the difference is not pedantry; it is the difference between a property of the language and a property of small programs.
If you would like a rigerous look at this reality, read on for the full paper. This is not an attempt to throw shade on Rust developers. Rust has many great properties. People like it. Languages have become popular for less. Memory Safety, or "safety" in general is not one of them, and we should stop pretending it is.