And you were right.

Bust++

C++ with a package manager.

I'm the author of this repo. I see some really angry comments, some of them even personal. Obviously I didn't think that just by tinkering with a compiler, I'd get personally attacked, but anyway, fair enough.

For those of you confused: yes, this started as a satirical project with the corroded lib. Then I thought "why not just remove the borrow checker?" without any real motivation. Then I just went ahead and did it. To my surprise, it was really simple and easy. I thought it would be heavily tangled into the rustc compiler, but once I figured out where the error emitter is, it was pretty straightforward.

I'm not sure about my long-term goals, but besides the joke, I genuinely think for debugging and prototyping purposes, I'd like the borrow checker to shut up. I'm the kind of guy that prints everything while debugging and prototyping. Maybe you're using a debugger, okay, but I don't. I don't like debuggers. It's just more convenient for me. So what constantly happens is I run into issues like: does this implement Debug? Can I print this after it moved? The borrow checker won't let me access this because of some other borrow. Stuff like that.

Another point is, as you guys are well aware, the borrow checker will reject some valid programs in order to never pass any invalid program. What if I'm sure about what I'm doing and I don't want that check to run?

In the repo there's a doubly linked list example. Without the borrow checker it's fairly simple and easy to implement. With it, you know how complicated and ugly it gets.

Anyway, have a good new year, and don't get angry over compilers, you know.

> Then I thought "why not just remove the borrow checker?" without any real motivation.

Reminds me of a chemistry kit I had as a kid. None of this tame, safe stuff you can buy these days. Mine was a gift from my dad and I never thought of asking him where he dug it up, but it had stuff like pure sulfuric acid in it.

One day, when I was done with all of the experiments I had planned to do, I decided to mix a few things and heat them up, just for fun, without any real motivation other than "let's see what happens".

Let's just say I was lucky we only had to replace some of the clothes my mom had left out for me to put away. ;)

> Another point is, as you guys are well aware, the borrow checker will reject some valid programs in order to never pass any invalid program. What if I'm sure about what I'm doing and I don't want that check to run?

Then you do it using the "unsafe" keyword, and you think long and hard about how to design and structure the code so that the unsafe code is small in scope, surface, and blast radius.

That's precisely what unsafe code is for: to get around the borrow checker and assert you know what you're doing. Of course, if you're wrong, that means your program will blow up, but at least you know that the culprit is hiding in one of those unsafe areas, rather than literally anywhere in the whole codebase.

Alternately, you can switch to a language with a different ethos.

The ethos of Rust is caring for memory safety so much that you willingly limit yourself in terms of what kind of code you write and you only step out of those limits reluctantly and with great care. That's something that resonates with a lot of people and Rust has been built on top of that for years.

If you suddenly take the product of those years of hard work, strip out the foundation it has been built on, and unironically offer it as a good idea, a lot of people won't like it and will tell you so. Mind, I'm not excusing the personal attacks, I'm just explaining the reaction.

Anything fun is dangerous. Or anything dangerous is fun. Something like that.

I ran into the borrowc so many times when doing OS dev. Which is why I hold the position that Rust is (not) a suitable language for OS development/kernels/embedded systems. In such scenarios, multithreading/multiprocessing is something you explicitly have to do, since although most systems that aren't x86 may start all processors simultaneously, your bootstrap code (should!) explicitly park all other cores before continuing. But the problem I always ran into was that Rust wanted me to do something weird for a system that was (not) multi-threaded. As in, I didn't even support threads of any kind. Or coroutines. But I still had to wrap statics in Lazy<T> or Rc<T> or something because "uwuw this is unsafe oh the world is going to end!" And all I wanted was to tell the borrow checker to shut up for once because yes, I actually did know what I was doing, thank you very much.

I get the idiom of "trust the compiler, it knows your code better than you". But there are also instances where the compiler just needs to trust the programmer because the programmer is, in fact, smarter than the compiler in those instances.

I think there is probably a way to do what you're doing with unsafe. You could write a library that copies handles and can dump potentially freed memory afterwards.

Some kind of cargo plugin that transforms all references in the project into pointers and casts prior to feeding to rustc would probably be the best practice and highly maintainable route I'd go. like "cargo expand" but with a fancy catchier name that encourages new users to rely on it. "cargo autofix" might work

There's definitely a way to do it without unsafe! It just isn't as simple as dropping one println out so.... Lets alter the compiler?

I gotta applaud that level of my-way-or-the-highway

This is incredible! I honestly think Rust is an awesome language because it has a lot of high-level niceties like HOF, powerful libraries but can simultaneously let you manage memory manually or put assembly next to your regular code - the borrow checker is an annoyance in a lot of cases like prototyping as you said. I would loove if this was an official mode that Rust supported, Rust could really work in any niche with that capability.

Thanks for explaining why you made Rust--! I figured it was just whimsical play, and I find it delightful. I'm especially delighted to hear that it wasn't even hard to disable the borrow checker.

I hope you will answer the question here from @dataflow about whether, without the borrow checker, compiler optimizations will emit incorrect code. Did you have to make further modifications to disable those optimizations?

You, sir, might one day belong to the Computing Hall of Fame, together with the creators of Brainf*k, Visual Basic, PHP, Javascript, ColdFusion, etc. :-p

You just need to master one package managed in depth and you will get what you really want with Modern C++.

Yes, that was my motivation.