11 ms·

To put things in context, Linus is being reasonable and wise and well-mannered once again. Wouldn't mind reading a few juicy expletives, to be honest.

miohtama 4y ago
I would rather believe in Rust than Santa Claus.
mustache_kimono 4y ago
As someone else in the thread notes, they seem to be talking past one and other. [0] Linus may view his job as "Saying No" but the way he does it still leaves a little to be desired, because his reasoning is sound here, but it's less "Follow my reasoning" than "You don't want to get yelled at again do you?" [0]: https://lore.kernel.org/lkml/CAFRnB2VPpLSMqQwFPEjZhde8+-c6LLms54QkMt+wZPjOTULESw@mail.gmail.com/ https://lore.kernel.org/lkml/CAFRnB2VPpLSMqQwFPEjZhde8+-c6LL...
darthrupert 4y ago
I wonder if he'll end up regretting opening this particular Pandora's box or will things stabilize eventually.
- thrown_22 4y ago
  If everyone who wrote a blogpost about how rewriting thing x in Rust would be amazing actually rewrote x in Rust it would already be the most popular language ever.
- detaro 4y ago
  What makes you expect it might not stabilize?
  - darthrupert 4y ago
    Because Rust people tend to be a bit extreme. But perhaps Rust people who are also kernel programmers are less so.
boardwaalk 4y ago
Context isn't your opinion.
staticassertion 4y ago
How is this context? Also how is it "wise" to get the definition of "safe" wrong while acting like a pedant?
wokwokwok 4y ago
>>>>> For GFP_ATOMIC, we could use preempt_count except that it isn't always enabled. Conveniently, it is already separated out into its own config. How do people feel about removing CONFIG_PREEMPT_COUNT and having the count always enabled? >>>> No (Linus) >>> As you know, we're trying to guarantee the absence of undefined behaviour for code written in Rust. And the context is _really_ important, so important that leaving it up to comments isn't enough. … >>> Do you have an opinion on the above? >> This message. Ie. No. you can’t make everyone play by your rules. (Linus, grumpily) > While I disagree with some of what you write, the point is taken. > But I won't give up on Rust guarantees just yet, I'll try to find ergonomic ways to enforce them at compile time. I mean, it doesn’t sound like he’s being petty or misunderstanding. They want special rules (which won’t work) to do runtime checking for rust code. That seems weird, right? Rust safety should be compile time. That’s the point… I dunno, maybe I don’t understand what’s being said, but I don’t think Linus is particularly wrong here, even if it’s kind of shouty.
- oconnor663 4y ago
  > Rust safety should be compile time. That’s the point… Array bounds checks are one of the most important safety measures Rust takes, and those have to happen at runtime (if the optimizer can't prove they'll never fire). Similarly, locking types like `Mutex` of course do all their locking and unlocking at runtime, though they also use the type system to express the fact that they will do that.

miohtama 4y ago

I would rather believe in Rust than Santa Claus.

mustache_kimono 4y ago

As someone else in the thread notes, they seem to be talking past one and other. [0] Linus may view his job as "Saying No" but the way he does it still leaves a little to be desired, because his reasoning is sound here, but it's less "Follow my reasoning" than "You don't want to get yelled at again do you?" [0]: https://lore.kernel.org/lkml/CAFRnB2VPpLSMqQwFPEjZhde8+-c6LLms54QkMt+wZPjOTULESw@mail.gmail.com/ https://lore.kernel.org/lkml/CAFRnB2VPpLSMqQwFPEjZhde8+-c6LL...

darthrupert 4y ago

I wonder if he'll end up regretting opening this particular Pandora's box or will things stabilize eventually.

thrown_22 4y ago
If everyone who wrote a blogpost about how rewriting thing x in Rust would be amazing actually rewrote x in Rust it would already be the most popular language ever.
detaro 4y ago
What makes you expect it might not stabilize?
- darthrupert 4y ago
  Because Rust people tend to be a bit extreme. But perhaps Rust people who are also kernel programmers are less so.

boardwaalk 4y ago

Context isn't your opinion.

staticassertion 4y ago

How is this context? Also how is it "wise" to get the definition of "safe" wrong while acting like a pedant?

wokwokwok 4y ago

>>>>> For GFP_ATOMIC, we could use preempt_count except that it isn't always enabled. Conveniently, it is already separated out into its own config. How do people feel about removing CONFIG_PREEMPT_COUNT and having the count always enabled? >>>> No (Linus) >>> As you know, we're trying to guarantee the absence of undefined behaviour for code written in Rust. And the context is _really_ important, so important that leaving it up to comments isn't enough. … >>> Do you have an opinion on the above? >> This message. Ie. No. you can’t make everyone play by your rules. (Linus, grumpily) > While I disagree with some of what you write, the point is taken. > But I won't give up on Rust guarantees just yet, I'll try to find ergonomic ways to enforce them at compile time. I mean, it doesn’t sound like he’s being petty or misunderstanding. They want special rules (which won’t work) to do runtime checking for rust code. That seems weird, right? Rust safety should be compile time. That’s the point… I dunno, maybe I don’t understand what’s being said, but I don’t think Linus is particularly wrong here, even if it’s kind of shouty.

oconnor663 4y ago
> Rust safety should be compile time. That’s the point… Array bounds checks are one of the most important safety measures Rust takes, and those have to happen at runtime (if the optimizer can't prove they'll never fire). Similarly, locking types like `Mutex` of course do all their locking and unlocking at runtime, though they also use the type system to express the fact that they will do that.