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