[withinboredom]

I struggled with the borrow checker because I’m smarter than it is, not because I haven’t worked with one before. Mainly I say “I’m smarter” because I’ve worked on big projects without it and never had any issues. Granted, I’ve only gotten in a fight with it once before giving up on the language, mainly because it forced me to refactor half the codebase to get it to shut up and I had forgotten why I was doing it in the first place.

[maleldil]

> I’m smarter than it is

Given how many important projects maintained by smart people have dealt with bugs that safe Rust makes impossible, I'm inclined to doubt that.

[nyrikki]

Let's be realistic, rust is great, especially compared to C.

But it shifts the need to memorize undefined behavior with the need to memorize the borrow checker rules.

If you are dealing with common system level needs like double linked lists, rust adds back in the need for that super human level memory of undefined behavior, because the borrow checker is limited to what static analysis can do.

IMHO, the best thing Rust could do right now is more clearly communicate those core limitations, and help build tools that help mitigate those problems.

Probably just my opinion, and I am not suggesting it is superior, but zig style length as part of the type is what would mitigate most of what is problematic with C/C++

Basically a char myArray[10];, really being *myArray is the main problem.

Obviously the borrow checker removes that problem, but not once you need deques treeps etc...

If I could use Rust as my only or primary language, memorizing the borrow checker rules wouldn't be that bad.

But it becomes problematic for people who need to be polyglots, in a way that even Haskell doesn't.

I really think there's ways for Rust to grow into a larger role.

But at this point it seems that even mentioning the limits is forbidden and people end up trying to invert interface contracts, and leak implementation details when they're existing systems are incompatible with the projects dogma.

It is great that they suggest limiting the size of unsafe code blocks etc....but the entire world cannot bend to decisions that ignores the real world nuances of real systems.

Rust needs to grow into a language that can adjust to very real needs without and many real needs will never fit into what static analysis can do.

Heck C would be safer if that was the real world.

I really do hope that the project grows into the role, but the amount of 'unsafe' blocks points to them not being there today, despite the spin.

[maleldil]

> But it shifts the need to memorize undefined behavior with the need to memorize the borrow checker rules.

With one massive difference: the borrow checker will tell you when you're wrong at compile time. Undefined behaviour will make your program compile and it will look like your program is fine until it's not.

I'd take that trade.

[marsten]

> But it shifts the need to memorize undefined behavior with the need to memorize the borrow checker rules.

You have a choice: Fight the borrow checker on the front end until your code compiles, or chase down bugs on the back end from undefined behavior and other safety problems. No single answer there, it depends on what you're doing.

Cognitive load is a big issue. In Rust I find this comes in a couple of phases, the first being figuring out what the borrow checker does and how to appease it. The second is figuring out how to structure your data to avoid overusing clone() and unsafe blocks. It's a bit like learning a functional language, where there's a short-term adaptation to the language, then a longer-term adaptation to how you think about solving problems.

You mention doubly-linked lists, which are a good example of a "non-star" data structure that doesn't nicely fit Rust's model. But: for how many problems is this the ideal data structure, really? They're horrible for memory locality. Those of us who learned from K&R cut our teeth on linked lists but for the last 20 years almost every problem I've seen has a better option.

[codr7]

Intrusive doubly linked lists are very nice in C for some types of problems, and don't have issues with memory locality.

[kstrauser]

> IMHO, the best thing Rust could do right now is more clearly communicate those core limitations, and help build tools that help mitigate those problems.

rust-analyzer is the tool that does this. Having it flag errors in my editor as I write code keeps me from getting too far down the wrong road. The moment I do something Rust thinks is goofy, I get a red underline and I can pause to consider my options at that moment.

[withinboredom]

In my particular case, I was absolutely sure it was safe without having to test it. Would it remain so forever? Probably not because software changes over time.

[eddd-ddde]

In those cases what you are supposed to do is write your logic using unsafe, and wrap it with lifetime safe APIs. That way your "smartness" joins efforts with rusts, and not-so-smart people can use your APIs without having to be as smart.

[tinco]

Did you rewrite the code base into C++ to avoid the borrow checker?

[withinboredom]

No, I just stopped contributing to the project and never touched Rust again.