I’d rather just have memory safety.

If all you give me is half measures, then I’ll either just use plain old C/C++ or I’ll switch to a totally different language. Maybe one with a GC so I don’t have to please some ownership thingy.

I think it's a common misconception that ownership is there to make you suffer compiler shenanigans. When in my experience it changes the way you model programs. Turns out, that structuring your program in a way were it's clear who owns what makes for easier to understand and debug programs. It's a bit analogous to static typing, saying I'll use a language like Python without type hints, because its gonna make me avoid compiler errors, is a bit short sighted when I plan on developing the piece of code for a longer time.

Here is a blog post that explains this in more detail https://without.boats/blog/notes-on-a-smaller-rust/.

Having to change how you write your program is the worst case of suffering compiler shenanigans that I can think of.

If you want to keep doing programming in a way you are already familiar with, and are not willing to change your way of thinking about programs, yes then it's a bad fit. If you want to write reliable programs, there is evidence that changing the way we think about and express programming problems, can have substantial effects on reliability.

You're assuming too much.

Not saying we shouldn't change anything.

I am saying that adding ownership is't the change that's needed, since you won't be able to convert most C code to that regime.

I said that it is necessary, but not sufficient. That does not mean it's a distraction: that means it is foundational.

Memory safety is a good thing to obsess over. It's just that we don't need ownership and borrow checking to get there.

You seem to have a preset opinion, and I'm not sure you are interested in re-evaluating it. So this is not written to change your mind.

I've developed production code in C, C++, Rust, and several other languages. And while like pretty much everything, there are situations where it's not a good fit, I find that the solutions tend to be the most robust and require the least post release debugging in Rust. That's my personal experience. It's not hard data. And yes occasionally it's annoying to please the compiler, and if there were no trait constraints or borrow rules, those instances would be easier. But way more often in my experience the compiler complained because my initial solution had problems I didn't realize before. So for me, these situations have been about going from building it the way I wanted to -> compiler tells me I didn't consider an edge case -> changing the implementation and or design to account for that edge case. Also using one example, where Rust is notoriously hard and or un-ergonomic to use, and dismissing the entire language seems premature to me. For those that insist on learning Rust by implementing a linked list there is https://rust-unofficial.github.io/too-many-lists/.

The GP commented once, politely disagreeing and describing their own experience. Looking over their past comments, I also don't see hostility to the ideals of memory safety or using Rust.

Seems like you made a passive-aggressive presumption.

Everything related to safety is on my list. (the list is big) I think big problems can be broken down into smaller ones.

I don't think it's very compelling to convert C code to a thing that gives you a safety half-measure. You'll still have security bugs, so it'll just feel like theatre.

huh? There are also security bugs in Rust, so it is theatre as well?

Pointer ownership could eliminate a class of bugs. And such an approach can be combined with run-time checks for bounds and signed overflow, and then you have a memory-safe C more or less (some minor pieces are still missing, but nothing essential),

Memory safety is what we should be aiming for.

I don't personally like Rust, I believe Rust achieves this. In Rust, if you don't use the unsafe escape hatch, then your bugs are at worst logic bugs. There won't be any kind of weirdness like that you got some math wrong in an array access and now all of a sudden an attacker can make your program execute arbitrary code.

On the other hand, this Cake thing just adds some ownership and when folks say it's problemmatic the first answer is "oh just tell it to ignore your function". That doesn't sound like memory safety to me. It's nowhere near Rust in that regard.

Rust does the same thing, though? If you are having trouble pleasing the compiler, you can use unsafe to get around it. Of course, the Rust people are a lot more active at telling you that what you wanted was actually wrong and bad, but it's essentially the same position.

No, it's not the same position, because you can write a lot of Rust code without ever using unsafe.

Ok, but how much Cake code can you write before having to disable the checker?

Cake disabled checks in a few linked list functions like pop_front pop_back.

Code that's full of memory bugs is likely full of other bugs too. Improving testing methodology, perhaps establishing official guidelines, would address ownership issues and more. The goal should be to write robust software, because robustness implies memory safety but the reverse is not true.