The Latest Progress On Rust For The Linux Kernel

[mdedetrich]

Eat shit:

https://doc.rust-lang.org/book/ch15-05-interior-mutability.html

Thanks for demonstrating you don't understand the difference between enforcing variants at runtime via a type and a borrow checker

[cl333r]

Of course, I fixed it but didn't erase the original .
Nothing changes it that the borrow checker has nothing to do with refcell.

Ok, let us fly a rocket to the moon, we have two rockets, a C and a Rust rocket. Both of the have a bug, because even in Rust you can have a bug.
Now, first flies the C rocket:
- the bug triggers, some race conditions occurs, some data get corrupted and now the rockets turns down and flies straight into a city nearby.
Ok, but the software didn't crash!
Now the rust rocket flies:
- the bug triggers, refcell does a panic, safely unwinds the program. Some overwatching hardware watchdog detects that, probably first tries to restart the program, if not goes into self destruct mode in the air, safely above the starting pad.

YOU HAVE NO IDEA WHAT A "safety critical system" is and how they work, the worst thing you want is a silent data corruption without any traces and logs.

That's the point you're getting wrong. I'm not talking about buggy C++ code, I'm talking about code that isn't buggy - that just has aliased mutability. Many (apparently beginner) Rust users think that aliased mutability = bug. It only means it could be a bug.
Yet another analogy: you have a penis but you're not a rapist, yet Rust would treat you like a rapist because Rust's train of thought goes like this: Rapist has penis, you have penis, therefore you have to be treated like a rapist, just in case, for security purposes, which in Rust's case means - crashing the app. And all I'm saying is that in like 99+% of the time people with penises are not rapists they're normal people and shouldn't be jailed "for security reasons, just in case".

[oleid]

That's the point you're getting wrong. I'm not talking about buggy C++ code, I'm talking about code that isn't buggy - that just has aliased mutability. Many (apparently beginner) Rust users think that aliased mutability = bug. It only means it could be a bug.
Yet another analogy: you have a penis but you're not a rapist, yet Rust would treat you like a rapist because Rust's train of thought goes like this: Rapist has penis, you have penis, therefore you have to be treated like a rapist, just in case, for security purposes, which in Rust's case means - crashing the app. And all I'm saying is that in like 99+% of the time people with penises are not rapists they're normal people and shouldn't be jailed "for security reasons, just in case".

Name one example where aliased mutability is desired behaviour and not a bug, e.g. in c++

[cl333r]

WTF does that even mean? There is no difference on RefCell behaviour relating on the code path it comes from.

Wrong. You can call into (say) a function that borrows() while the object is already borrowed, and some other code can call that function with the object unborrowed, in one case the same function fails, in another succeeds.

That's not a Rust fanboy train of though, that's a correct train of thought. Having a program that can misbehave but this time around didn't because we got lucky, that's utterly worthless. The point is to develop a program that CAN'T misbehave. By the way, if you think that having RefCell in its std lib makes Rust somehow bad, then I presume you also hate C11 for having mtx_t since multiple mutating aliases and data write races are very closely related problems,

Lucky? You're "lucky" with the Linux kernel? And Rust programs "can't misbehave"? Sorry you're too stupid to argue about nuances you don't or can't even grasp. Have a nice day.

[dragonn]

Many (apparently beginner) Rust users think that aliased mutability = bug. It only means it could be a bug.

With is why Rust does have in std for example RefCell with allows you to in some cases "aliased mutability". But the difference is that when writing C/C++ code you will not know you are doing aliased mutability, with can in some cases lead to a hidden bug and misbehavior.
In rust you always you are doing aliased mutability and when you do it the wrong way it will in a predict stop the program and show where the error happen.
So no how is Rust worse in the case then C/C++? They only thing it forces on you that you know you are doing aliased mutability.

About analogy, they is one small problem, code isn't people, but you might compare code to tools. Why does most countries in the world not allow having weapons by civilist even when most of them wouldn't do any harm with it and would have it only for protection? Because "for security reasons, just in case", when you want a weapon you need to go through some tests and have a valid reason for it, not "just in case for defending" with is exactly what Rust does.
Rust doesn't prevent from writing absolutely bad code, but it makes it hard for you and allows other developers see issues in your code right away.

[cl333r]

Name one example where aliased mutability is desired behaviour and not a bug, e.g. in c++

Desired behavior for me, maybe not for you: removing items from a vector looping from end to start, removal decided based upon certain item criteria.

[jacob]

Wrong. You can call into (say) a function that borrows() while the object is already borrowed, and some other code can call that function with the object unborrowed, in one case the same function fails, in another succeeds.

And...? If that happens, RefCell will fail, in the same way every time. Which of these two functions will get there first is irrelevant, the point is that the situation will happen and RefCell will tell you where and when it happened.

But if the panicking (which is a GOOD THING) still bothers you, why you don't at least look up its documentation? You would see, among other things, that it has a "try_borrow()" method that will not panic but instead return an error so that you can handle the conflict gracefully if needs be. I'm not aware of any other language that would let you detect the situation and handle it.

BTW don't be mistaken by the word "borrow" here, it doesn't imply that it's somehow related to the borrow checker as you seem to believe,

Lucky? You're "lucky" with the Linux kernel? And Rust programs "can't misbehave"? Sorry you're too stupid to argue about nuances you don't or can't even grasp. Have a nice day.

Well duh, yes, of course you are lucky with the kernel. Have you never seen a non-graceful kernel crash? I have. Have you never seen a security vulnerability caused by a data race condition? I have.

That's why safety critical systems don't usually use general-purpose OSes.

[cl333r]

With is why Rust does have in std for example RefCell with allows you to in some cases "aliased mutability".

No it doesn't allow, that's the point of RefCell - to crash if it detects aliased mutability. And aliased mutability != bug.

[oleid]

Yet another analogy: [...]

Yet another analogy:
you like surfing on the roof of cars, but you never had an accident, yet Rust would treat you like a looser because Rust's train of thought goes like this: Roof surfing is really dangerous, you could fall down and cause accidents, therefore you have to be treated like a noob, just in case, for security purposes, which in Rust's case means - crashing the app. And all I'm saying is that in like 99+% of the time people surfing on cars don't cause accidents, they're normal people and shouldn't be jailed "for security reasons, just in case".

[mdedetrich]

BTW don't be mistaken by the word "borrow" here, it doesn't imply that it's somehow related to the borrow checker as you seem to believe,

Want to bet how many pages it will take for him/her to realize that enforcing borrow semantics via an option standard library runtime mechanism is not the same thing as the borrow checker?