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