[1] https://lukefleed.xyz/posts/who-owns-the-memory-pt1/

It works in the sense that the borrow checker stops bothering you and the compiler will compile your code. It will even work fine as long as you don't write code which invokes UB (which does include code which would not pass the borrow checker, as the borrow checker necessarily rejects valid programs in order to forbid all invalid programs).

In the following example, z is dereferenced one time and assigned to both x and y, but if z and x are aliased, then this is an invalid optimization.

    fn increment_by(x: &mut i32, y: &mut i32, z: &i32) {
        *x = *z;
        *y = *z;
    }

This is a binary assumption that you can understand to evaluate to "true" in the absence of a borrow checker. If it is "false" it halts the compiler

Evidently millions of people want broken garbage, Herb Sutter even wrote a piece celebrating how many more C++ programmers and projects there were last year, churning out yet more broken garbage, it's a metaphor for 2025 I guess.

You can already disable it locally: the unsafe keyword is for that.

It doesn't make much sense to globally relax restrictions of Rust's references to be like C/C++ pointers, because the reference types imply a set of guarantees: must be non-null (affects struct layout), always initialized, and have strict shared/immutable vs exclusive access distinction. If you relax these guarantees, you'll break existing code that relies on having them, and make the `--yolo` flag code incompatible with the rest. OTOH if you don't remove them, then you still have almost all of borrow checker's restrictions with none of the help of upholding them. It'd be like a flag that disables the sign bit of signed integers. It just makes an existing type mean something else.

If we can't have this, C itself offers zero benefit over assembly.

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.

    fn main() {
        let a = String::from("hello");
        let b = a;
        println!("{a}");  // Works! Prints: hello
    }

One example might be a tree-like struct where a parent and child have references to each other. Even if everything is cleaned up properly, the borrow checker has no way to know that when the struct is created. Solving it requires unsafe at some point, usually through something like RefCell.

No, not at all. The examples at the beginning of the article show this - they'll execute correctly. The borrow checker is quite conservative, and rules out all sorts of code that won't (normally!) cause runtime errors.

It's fairly easy to see this if you think about the core of Rust's ownership model: every value in Rust has a single owner. The compiler enforces that for any value, there's either one mutable reference or any number of immutable references to it at a time.

This model has the advantage of being simple, easy to reason about, and ruling out large classes of errors. But like most static checks, including e.g. traditional type checks, it also rules out a great deal of otherwise valid code.

It's easy to think of examples in which you have multiple mutable references to a value that won't cause errors. Aside from trivial examples like in the article, in C-like languages you can have many concurrent mutable references to the same mutable value. You can safely (with some caveats) manage access to it via locks, protocols, documentation, or just being careful. Rust with the borrow checker simply doesn't allow multiple concurrent mutable references to the same value to exist. Rust without the borrow checker, as in the article, would allow this.

I think fighting the borrow checker is more like a rite of passage. Rust is not my favorite language but the borrow checker is great.

The two main things the compiler allows in an unsafe block but not elsewhere are calling other code marked "unsafe" and dereferencing raw pointers. The net result is that safe code running in a system that's not exhibiting undefined behaviour is defined to continue to not exhibit undefined behaviour, but the compiler is unable in general to prove that an unsafe block won't trigger undefined behaviour.

You can side-step the borrow checker by using pointers instead of references, but using that power to construct an invalid reference is undefined behaviour.

C/C++ is great at giving that false sense of competence. Then suddenly you're getting a segfault, and you'll never determine why with beginner knowledge, since the crash-line and the mistake-line aren't even in the same zipcode (and or same Git changeset).

Rust forces you to not "skip" knowledge steps. If you have a gap in your knowledge/understanding the compiler will call you out immediately. C/C++ will happily let your dangerously bad code compile and kinda-run, until it doesn't.

I'm not anti-C/C++, I've actually written tons. I love C in particular. But saying that they're beginner-friendly feels wrong, a lot of people quit the language because "random stuff" starts to go wrong, and they lack the knowledge to determine why.

I think we may safely assume that Rust's designers are smart people that have made every effort to keep Rust as simple as it can be, given its intended use.

Here's rust code:

    fn main() {
        println!("Hello, world");
    }

    #include <iostream>

    int main() {
      std::cout << "Hello World!" << std::endl;
      return 0;
    }

I feel torn with this sentiment.

On one hand, I totally agree. Rust's "foreign" ideas (borrowck, lifetimes, match expressions, traits, etc) make it harder to learn because there's a bunch of new concepts that nobody has really worked with before. Some of this stuff - lifetimes and borrows especially - really demand a lot of imagination on behalf of the programmer to be able to understand what's actually going on. The amount of thinking I do per shipped line of code seems higher for rust than it does for languages like Go, Typescript and C#. And sometimes C.

On the other hand, I learned C about 30 years ago. Not only have I forgotten how hard it was to learn, but I had the brain of a teenager at the time. And now I'm in my (early) 40s. I'm scared that some of the struggle I went through learning rust came because my brain is old now, and I've forgotten what its like to be out of my depth with a programming language. Learning rust requires shaking up some old neurons. And that's really good for us, but it sucks.

In reality, I think its a bit of both. I've been using rust a lot for about 3-4 years now. Its gotten way easier. But I still prototype a fair bit of algorithmic code in typescript first because I find TS makes it easier to iterate. That implies rust is actually more complex. But, some people pick rust as their first language and it seems to work out fine? I'm not sure.

> I don't think the borrow checker forced rust to be such a complicated language.

Which parts of rust seem complicated? I've found a lot of the things I struggled with at first got a lot easier with familiarity. I love traits and match expressions. I love rust's implementation of generics. I love most things about cargo and the module system. But also, some parts of rust annoy me a lot more now, a few years in.

I disagree with your comment. I think the main source of complexity in rust comes from lifetimes - which are required by the borrow checker. For example, its not obvious when you need to put lifetimes in explicitly and when you can elide them. When does the borrow checker understand my code? (Eg, can you mutably borrow two different elements in an array at the same time?). I also still don't really understand Higher-Rank Trait Bounds.

I also still find Pin really confusing. In general I think async and Futures in rust have some big design flaws. It also really bothers me that there's a class of data types that the compiler can generate and use, which are impossible to name in the language. And some of the rules around derive and traits are annoying and silly. Eg derive(Clone) on a generic struct adds the constraint T: Clone, which is straight out wrong. And rust needs a better answer to the orphan rule.

But in general, if you take out the borrow checker, I find rust to be simpler and easier to read than most C++. There's no headers. No exceptions. No wild template nonsense. And there's generally way less weird magic going on. Eg, Foo(bar); could mean about 8 different things in C++. Rust isn't like that. Rust is simple enough you can just read the standard library, even as a beginner, and its great. C++'s STL is a disaster to read.

Rust is definitely more complex than C. But you do get some lovely features for that extra cognitive overhead. Whether or not thats worth it is up to you. In general - and I've been saying this for years - I feel like the language I really want is rust 2. I can't wait for someone to take rust's best ideas and refine them into a simpler language.

But with Rust, you have to understand almost all of the language very intimately to be a productive programmer, and Rust is not that great at hiding complexity, as in fairly innocious decisions often have far-reaching consequences down the line.

I completely understand your frustration about how common shallow-indignant comments are. But it doesn't help to post shallow-indignant or snarky comments of your own about it - it just produces even more of the same, or worse.

The way to combat shallow-indignant, predictable, tedious, etc., threads is to find something that you're genuinely curious and open about, and post from that place instead.

https://news.ycombinator.com/newsguidelines.html

By “this” I mean “spend all their time fighting against the language/framework because they don’t like it, rather than just picking a different language.”

You couldn't pay me to work with them