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.