Ygg2

You're just splitting hairs and trying to weasel around the fact

No. I said borrow checker allows unbound lifetime. I didn't disagree with you. I noted you didn't read the argument.

If you know what I meant, then what's up with your snarky comment about "So much for effectively disabling stuff"?

Because your original code looked like trying to cast mut u32 to pointer.

you did effectively disable the borrow checker in safe parts

So this code (https://play.rust-lang.org/?version=stable&mode=debug&editio...) runs now?

Effectively means achieving the goal in satisfying manner.

Writing unsound code is less of effectively disabling borrow checker and more of a hack.

Think about it, if using Java unsafe I gain access to underlying HashMap array and do weird stuff to the HashMap invariants am I effectively turning HashMap into Array or am I doing a hack job?

Edit: By that logic since there is so much unsafe in the code base isn't borrow checker effectively already disabled? You can argue semantics but no, borrow checker isn't de facto or de jure invalidated by unsafe blocks.

It's invalidated by unsound unsafe and that's on code writer to fix.

Proof:

You just listed examples of unbounded lifetimes.

I said "effectively disable". For example:

Not sure what you meant by this example since it doesn't compile. It seems the borrow checker caught your mischief. So much for effectively disabling stuff :P

You haven't effectively disabled anything; you just (tried to) wrote unsound code that washes one mutable ref as another. This stuff is allowed provided shared refs are never accessed at the same time (for example, panicking upon reading reference_b).

What you probably meant is https://play.rust-lang.org/?version=stable&mode=debug&editio...

But you know what? If you're dabbling in unsafe, you have this big button called Tools in the playground. Choose Miri, then run your code; it will display large Undefined behavior. It even highlights the `trust_me_bro` function.

Hell, run this with UBSAN, ASAN, and other C tools. They will probably catch any such behavior.

Andreas Kling talked about it. It boils down to C++ interop sucks (no surprise for lang made by Apple), ecosystem is tiny, Rust works well enough with LLMs.

https://youtu.be/DbHjKi_jASY

Mu. Invalid question. Rust doesn't disable compiler features. It gives you extra set of footguns when you ask for it.

As for the actual unloaded question, "What's the point of unsafe in Rust?" it is to contain and make it easier to identify sources of UB.

If you saw the "Institute for Typesafe Memetic Research" and thought, "This is the den of Rust evangelists!" I don't want to break your illusion, because it's much funnier this way. Especially since there are like two people that like Rust on Twitter, and I'm one of them.

BTW did you hear about this:

https://babylonbee.com/news/democrats-say-they-are-perfectly...

OR

https://www.youtube.com/watch?v=bXEddCLW3SM

Calling him "smelley"?

Turnabout is fair play.

Frankly, that entire "Institute for Type Safe Memetic Research" seems like either an elaborate satire or an account run by genuinely insane people who think type and memory safety are paramount societal issues.

You've been had. Your entire rant means the bait worked.

True, but unsafe let's you conjure up any lifetime you want

The only thing unsafe does is let you have an unbounded lifetime. As I said, it doesn't check those:

   fn get_str<'a>(s: *const String) -> &'a str {
       unsafe { &*s }
   }

if you generously sprinkle pointer dereferences in unsafe code, you effectively disable the protection provided by the borrow checker

You don't disable anything. You wrote a "trust me compiler" block, and compiler trusted you.

Rust won't ever protect from all possible problems, just the ones the compiler handles.

You didn't just quote The Institute of Typesafe Memetic Research as proof of anything...

It's a shitposting, hyperbolic bait account. As funny as calling Andrew Kelley Smelley, it's not meant to be taken as gospel.

Unsafe Rust doesn't automagically disable typesystem (& borrow checker, but lifetime are a sort of types).

Once raw pointer is turned into a T, &T or &mut T, the borrow checker is on.

Developer & time-cost of a rewrite is a big unknown... An optimist might say this cost has vanished.

I wouldn't say it vanished. I'd say it moved from unknown to known. It's highly likely that for code the size of Bun the price is around 200k dollars of tokens + a month of programmers time to monitor it.

Shipping a rewritten product is -by itself- an unknown risk. That still holds. You can do all the testing you want, but your test suite != your clients environment(s? multiply by number of users or target platforms).

Fair point.

That said, it seems the number of relevant platforms is shrinking. Both on the hardware side - x86_64 AMD, x86_64 Intel, and aarch64. On the OS side, you have Linux, Mac and the dying Windows.

Still, it seems with enough tests and original source code, you can limit this risk to a few edge cases.

All in all Joel's article held up pretty well

Aside from the fact that it mostly applies to commercial endeavors[1], it still missed the mark on old code decaying over time.

Turns out being exposed to the Internet has a chance to turn even old code sour.

[1] If you don't care about your users, or you care more about pleasing/attracting new developers, then points made in his article don't make rewriting it that bad.

By the engineer's wit of course!

Seeing how the Rust compiler isn't an LLM, it can't really work on wit.

From the POV of a programmer, how would you implement an unsafe block? What is disabled vs what's enabled?

By detecting undefined behavior

Say you are tasked with making Miri; how do you detect violations of these rules?

Ok, and how does, in your opinion, compiler rules enforcement work in an unsafe block?

And how does Miri help solve this issue?

No. I just think you're taking judge by number of segfaults out of context. That said, I wrote this before the edit.

People were for a few weeks commenting on why Jarred didn't write that Rust blog post.

Here are the comments:

https://news.ycombinator.com/item?id=48251340

https://news.ycombinator.com/item?id=48241734

https://news.ycombinator.com/item?id=48240996

Now he published it; it's a hit piece. Damned if you do, damned if you don't.

It's funny, but I think the article is showing it's age. It's no longer true.

In hindsight having automated auto complete rewriting your code base wasn't something on 2000's radar.

Now switching from language to language is much easier. Just for Rust, there was Ladybird and Bun complete rewrite, that ran into zero things that Joel rallied about.

Good job falling for the Zig propaganda. I say that half-jokingly.

EDIT: You can't be serious people. Rust unsafe is safer than C, if for nothing else, for knowing which pointers are aliasable.

Without base rate you're comparing #X in a city vs #Y in a continent and drawing conclusions from that.

It's not even wrong.

I remember watching HN and seeing every time there was something Rust related trending, there was ALWAYS a post made shortly after trying to hype Zig

The Zig Evangelism Task Force has supplanted Rust as the premier hypebeast. And they'll be supplanted by the NEXT BIG THING.

Where did I say Rust's borrow checker predates lifetimes?

I'm saying you have to be as meticulous as a borrow checker. Not as strict, of course, but you have to analyze each pointer, how and when it's used, and then cross-reference with the documented lifetime.

Just like thread safety existed before Rust made it explicit. Now you don't need to investigate if data is thread safe if it's `Send + Sync`.

This is a job humans suck at and compilers excel at. With some caveats. There will be edge cases that will need to be manually proven.

I don't because I think the GP is blaming the tech, not the actual culprit - a bit like blaming the invention of fridges for people hiding the body. LLMs can be made and hosted independently of OpenAI and Anthropic.

TBH in hindsight it seems that the Bun acquisition was also for the PR stunt they just did with the Rust porting.

The events went roughly like this:

- Anthropic used Bun. So they acquired it.

- Bun made some LLM derived patches for Zig. They were rejected due to Zig no-LLM stance.

- Bun couldn't get patches in, so they switched to Rust.

Was it a PR stunt, an attempt to pressure Zig maintainers into changing AI stance, or just doing the fastest thing possible? It's difficult to tell. I'm inclined to believe the last option.

As easy as it is to blame Bun for a PR stunt, it's also possible that you can't really associate with someone who rallies against your employer/owner.

AI is an inherently anti-social, anti-human technology, and this rewrite is the perfect example of that.

Not really. LLMs are a tool, and they do possess some interesting properties, but they are, in essence, a very surprising auto-complete.

No, what sucks is the AI companies marketing them as if they are The Holy Grail. And people are assuming that somehow LLM -> AGI -> ASI, even though there isn't really a causal link to be had, and acting like it's The Singularity.

I don't blame autocomplete for fucking up RAM, labor and god knows what else. I blame the idiots (at OpenAI and Anthropic) buying all RAM stocks and pretending this shit is any way good for anyone.

Disclaimer: I'm bullish on Rust. And I think LLMs are overhyped, and kind of overhated.

Honestly, I think it would have been better if he had done the smart thing and ignored the noise around Bun's Zig -> Rust, and focused on code.

If he was willing to ride the coattails of Zig being hyped by Bun, then he should have taken the hit when Zig and Bun parted ways.

Hell, if he is that happy that they are leaving, he shouldn't have written that he is happy. Just smile and wave...

So now Jarred wrote a very matter-of-fact post about migrating Bun to Rust, and Andrew Kelley wrote a ranty blog about Jarred sucking at Zig, and being glad he's gone.

If you are writing in C-like codebase and aren't tracking lifetimes and ownership at least as well as a borrow checker you're opening yourself to CVEs.

Fifteen years ago World of Warcraft was at its peak.

Sixty years ago the model was you go to an arcade cabinet, and you get charged every time you died (Credit: https://www.penny-arcade.com/comic/2026/07/03/returnal-3).

Ideally, they want cabinet in every home, you pay electricity for it, you buy overpriced Bluey skins, you buy your lives, you buy ads, and pay them every second for the pleasure, while not owning even the cabinet.

It's also Ok to ban discussions that will lead nowhere or cause flame wars.

Nah. You have to be very intentional in GC languages to avoid extra allocations.

It doesn't take much for one memory inefficient dep to drag down the entire app.

Meanwhile, Rust took its time.

Yes, this is the difference between a BDFL. A single person can make a decision faster, than a group of people. And consensus often leaves most people a bit miffed.

Again, the issue starts when the dictator grows mad and starts making decisions that make every contributor uncomfortable.

To my horror, many software projects were accepting LLM-generated code. I had thought LLMs were unpopular among developers.

Why would a really stochastic auto-complete and analyzer be disliked by developers? LLMs are a useful tool, sometimes, but they aren't the <WE WILL REPLACE ALL WORKFORCE BY 2028> levels of hype that current frontier labs need to justify their costs.

But Memory Safety!

I'd be genuinely flabbergasted if Zig ends up as safe as Rust without any overhead. So, no, adding Fil-C doesn't count. We have memory safety with overhead. We call it Java/C#/JavaScript/Go/<INSERT VM LANG HERE>.

Honestly, I'm in partially disagree camp. What matters is how much time it saves.

A good WYSIWYG editor will run circles around the fastest text editor. Even if WYSIWYG is a bit slower to open.

It would be preferable for software to be more focused and faster over time, but that doesn't attract people to it.

Actually I suspect that Rust is a Silver Bullet in that sense.

Not really. If anything I'm pretty sure Fred would compare it to Ada:

    > Nevertheless, Ada will not prove to be the silver bullet that slays the software productivity monster, It is, after all, just another high-level language, and the biggest payoff from such languages came from the first transition, up from the accidental complexities of the machine into the more abstract statement of step-by-step solutions.

No. Anyone expecting that hasn't read No Silver Bullet essay.