The Latest Progress On Rust For The Linux Kernel

[cl333r]

My apologies. I assumed you would be able to understand the difference between a language construct and a type in the standard library.

You wrote only this, nothing about "language construct vs std":

That would be bad indeed. Luckily, that's not even close to how the borrow checker works.

Then I proved to you that the borrow checker does in fact work at runtime too and you're trying to change the subject to a totally different topic. Pathetic.

I'm also not entirely sure why you're linking to a 5 year old version of the book

It came out first in a google search and in 5 years didn't change.

[jacob]

Another stupid Rust fanboy.

https://doc.rust-lang.org/1.8.0/book/mutability.html

OK so first thing, RefCell has nothing to do with the borrow checker. Secondly, RefCell is a way to support interior mutability, which is usually only needed in very specific cases. But thirdly and most importantly, the point of RefCell is to enforce an invariant that cannot be checked statically by monitoring it at runtime. It's not about panicking for no reason as you said, it's about detecting, during debugging, cases of multiple uncontrolled mutating aliases so that they don't occur in prod code.

Because what's the alternative? In C or C++, the program wouldn't magically work better in the presence of such aliases. But instead of panicking in a predictable and reproducible manner with a clear debug message, so that it can be fixed, it would misbehave silently, suffer from use-after-free, race conditions and other goodies, and of course crash but usually not deterministically, and in a way that can be very difficult to reproduce and diagnose.

How exactly is that supposed to be better, stupid fanboy? Especially in a safety critical system as you said?

[dragonn]

Then I proved to you that the borrow checker does in fact work at runtime too and you're trying to change the subject to a totally different topic. Pathetic.

Pathetic is you, borrow checker has nothing to do with the borrow checker, it is not a part of it as jacob said too. (EDIT of course I mean RefCell)
Even if Rust didn't provide RefCell out of the box nothing prevents your from writing one yourself, they are not as such complicated. You can even with easy write them in C/C++ too.
Rust can not protected from all errors you will do writing your program but it really tries to do the best and protected your from the most common ones and most stupid ones.
Also, I prefer a panic at runtime from RefCell then getting some weird data corruption in C.

It came out first in a google search and in 5 years didn't change.

Ah yes, THE EXPERT by googling for 5 minutes on the topic, true pathetic.

[cl333r]

OK so first thing, RefCell has nothing to do with the borrow checker.

Dead wrong.

Secondly, RefCell is a way to support interior mutability, which is usually only needed in very specific cases.

Meaningless. A car is also "needed only in very specific cases", almost anything works this way.

It's not about panicking for no reason as you said

Wrong again, I said:

because the borrow checker saw aliased mutability or something

But instead of panicking in a predictable and reproducible manner

Meaningless, it prints where and why it happened but the same chunk of code behaves differently depending on what path it came from - not too predictable if you ask me.

it would misbehave silently, suffer from use-after-free, race conditions and other goodies, and of course crash but usually not deterministically, and in a way that can be very difficult to reproduce and diagnose.

Typical Rust fanboy train of thought. Can misbehave != would misbehave. Just because you have aliased mutability doesn't mean it is misbehaving, it means it could.

How exactly is that supposed to be better, stupid fanboy? Especially in a safety critical system as you said?

Not crashing the app is better when the plane is landing the last thing you want is the software to crash, in this case the Rust is the opposite of "safety critical system".

[cl333r]

Pathetic is you, borrow checker has nothing to do with the borrow checker.

Brilliant, edit that out until someone else sees it.
And I'm gland you're sting hanging onto the nonsense of why I didn't link to the latest version which means you're desperate.

[mdedetrich]

Brilliant, edit that out until someone else sees it.
And I'm gland you're sting hanging onto the nonsense of why I didn't link to the latest version which means you're desperate.

To be honest, you have zero clue what you are talking about and its evident in your responses.

RefCel has nothing to do with the borrow checker, its an abstraction that allows reference counting (similar to how Python works but a lot more efficient) hence the Ref in its name (as opposed to just Cell which doesn't have this reference counting mechanism). Using this deranged logic, you can also claim that a GC is a borrow checker (hint: its not)

The borrow checker, i.e. the process that checks the flow of memory using linear type system is a purely compile time construct and when people say "borrow checker" thats what they mean. RefCel can be used in cases where the borrow checker can't prove something, but that in of itself doesn't mean its a borrow checker.

[dragonn]

Brilliant, edit that out until someone else sees it.
And I'm gland you're sting hanging onto the nonsense of why I didn't link to the latest version which means you're desperate.

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

Not crashing the app is better when the plane is landing the last thing you want is the software to crash, in this case the Rust is the opposite of "safety critical system".

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.

[cl333r]

To be honest, you have zero clue what you are talking about and its evident in your responses.

RefCel has nothing to do with the borrow checker, (bla-bla)

Eat shit:

Enforcing Borrowing Rules at Runtime with RefCell<T>


Unlike Rc<T>, the RefCell<T> type represents single ownership over the data it holds. So, what makes RefCell<T> different from a type like Box<T>? Recall the borrowing rules you learned in Chapter 4:

• At any given time, you can have either (but not both of) one mutable reference or any number of immutable references.
• References must always be valid.

With references and Box<T>, the borrowing rules’ invariants are enforced at compile time. With RefCell<T>, these invariants are enforced at runtime. With references, if you break these rules, you’ll get a compiler error. With RefCell<T>, if you break these rules, your program will panic and exit.

The advantages of checking the borrowing rules at compile time are that errors will be caught sooner in the development process, and there is no impact on runtime performance because all the analysis is completed beforehand. For those reasons, checking the borrowing rules at compile time is the best choice in the majority of cases, which is why this is Rust’s default.

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

[oleid]

You wrote only this, nothing about "language construct vs std":


Then I proved to you that the borrow checker does in fact work at runtime too and you're trying to change the subject to a totally different topic. Pathetic.


It came out first in a google search and in 5 years didn't change.

Let's assume for a moment that RefCell was 'the borrow checker'. It is opt-in, i.e. you have to write code using that construct yourself. So it is an active process done by the programmer. Nothing the compiler magically inserts. So what is the problem?

[jacob]

Dead wrong.

Sorry to break it to you but you have no freakin' idea. There is no connection at all between the borrow checker and RefCell. The borrow checker is a compiler pass, RefCell is part of the standard library.

Meaningless. A car is also "needed only in very specific cases", almost anything works this way.

Exactly. And you want to be sure that your car's brakes will always work and that it won't catch fire, not just that last time you used it it was fine.

Meaningless, it prints where and why it happened but the same chunk of code behaves differently depending on what path it came from - not too predictable if you ask me.

WTF does that even mean? There is no difference on RefCell behaviour relating on the code path it comes from. Either there are uncontrolled multiple mutating aliases (= it panics) or there aren't (= it doesn't panic), regardless of which code path reached it. And it will be the same every time, which is the whole point, instead of letting the bug manifest itself through all kinds of undefined behaviour and crashes down the road (usually much later).

Typical Rust fanboy train of thought. Can misbehave != would misbehave. Just because you have aliased mutability doesn't mean it is misbehaving, it means it could.

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,

Not crashing the app is better when the plane is landing the last thing you want is the software to crash, in this case the Rust is the opposite of "safety critical system".

So you would actually want to be treated on the TERAC 25? Look it up. It was a radiotherapy machine that killed several people and mutilated a few more with severe burns etc., all due to two fundamental bugs, one of which was due to uncontrolled concurrent mutation. Of course no-one even knew about it until it was too late, because usually it worked and didn't misbehave - unless it did.

Or you would want to fly on a 737MAX before the MCAS was fixed? That wasn't due to mutation, but all the same, it was a system that could potentially misbehave but didn't, so everything was fine, right? Of course, one day it eventually did misbehave...