[flagged]
This comment is interesting and adds to the discussion but it would be quite a bit better without the flamewar-style swipes in the last sentence :)
The state of the kernel Rust experiment
81–90 of 148 posts
Re: The state of the kernel Rust experiment
#82Earlier quoted context omitted.
What does bias have to do with empirical evidence? Disprove that than driveling about non-tech stuff.
[flagged]
So you can't, and if a "dumbass" like me can understand the importance of empirical evidence but you can't, maybe read up on rational thinking instead of lashing out emotionally.
Re: The state of the kernel Rust experiment
#83[flagged]
That was definitely me, you got me. How did you know from my comment about a potential Alpha LLVM backend?
Re: The state of the kernel Rust experiment
#84Earlier quoted context omitted.
I do not think it is weird. Every C bug was taken as clear evidence that we need to abandon C and switch to Rust. So the fact that there are also such bugs in Rust is - while obvious - also important to highlight. So it is not weird hatred against Rust, but hatred against bullshit. And considering that most of the code is C, your 150 C vulnerabilities is a meaningless number, so you still continue with this nonsense.
One C bug was not taken as clear evidence that we need to abandon C and switch to Rust. Hundreds of thousands of very similar bugs, over decades, in common code patterns were. I’ve never understood how other C or C++ developers could seriously question whether Rust solves any safety problems at all. Maybe the tradeoffs aren’t worth it for a particular use case, but how could you find it unimaginable that even just en…
Giving the size and age of the C ecosystem, the number of bugs is not really a valid argument. We will see an increasing numbers with Rust as Rust is increasingly used. I also do not question that Rust solves some problems. It just solves them rather badly and at high cost while bringing new problems.
I looked at firefox code a decade ago, it was a complete complex nightmare mix of different languages. I can see that this motivated starting something new, but it was not a clean C code base (and not even C).
Re: The state of the kernel Rust experiment
#85Earlier quoted context omitted.
> And not individuals who work at Microsoft does not count. How in the world does this not count? People act in the interest of those who pay the bills.
>How in the world does this not count? People act in the interest of those who pay the bills. Guilty by association? So do you have evidence of Microsoft the company doing this or not?
Re: The state of the kernel Rust experiment
#86Earlier quoted context omitted.
> Saying these features could appear everywhere is no difference from "unsafe" possibly appearing everywhere in Rust. That's not true in practice: Unsafe code is clearly delineated and can be 100% correctly identified. In C, usage of dangerous features can occur at any point and is much harder to clearly separate.
First, if "unsafe" worked so well 100% time, why did we have this bug? (and many other) So this already obviously wrong statement. Then yes, you can use dangerous features in C at any time, but obviously you can also use "unsafe" at any time. The only difference is that "unsafe" is clearer to recognize. But how much this is worth is unclear. First, if you do not invalidly reduce the discussion to only memory safety,…
> logic bugs outside "unsafe" can cause bugs unsafe.
This is the wrong understanding of Rust's unsafety encapsulation. For example, no logic bug outside of `unsafe` can cause undefined behavior of Rust std's `Vec` abstraction, which is using underlying unsafe to build.
The point that "because unsafe is used so the entire Rust program is also unsafe" is a real major myth. It's as absurd as saying "because Java runtime using unsafe underlying to build so Java is also unsafe".
Re: The state of the kernel Rust experiment
#87Re: The state of the kernel Rust experiment
#88[flagged]
This comment is interesting and adds to the discussion but it would be quite a bit better without the flamewar-style swipes in the last sentence :)
Please explain how it adds to the discussion about different ways to broaden supported Rust target architectures. Because both have the word Rust in them?
Re: The state of the kernel Rust experiment
#89Earlier quoted context omitted.
> You and Greg are sorely mistaken. Greg Kroah-Hartman has been a Linux kernel developer for 25 years, responsible for large parts of the kernel. You’ve been a hacker news commenter for 1 day. Could you pipe down with these wild claims that you know better than him? Also, please don’t complain about downvotes. It’s tedious to read.
[flagged]
This is a valid appeal to genuine expertise not authority.
Re: The state of the kernel Rust experiment
#90Earlier quoted context omitted.
Safe Rust eliminates some of the more common memory bugs in C. The bug under discussion was written in unsafe Rust—but even that doesn't obviate the huge advantages Rust has over C. Even unsafe Rust, for instance, has far fewer UB gotchas than C. And with Rust, you can isolate the tricky bits in 'unsafe' blocks and write higher-level logic in safe Rust, giving your code an extra layer of protection. C is 100% unsafe—…
The safest computer is a rock. The point is that when you start using rust in the real world to get real work done a lot of the promises that were made about safety have to be dropped because you need to boot your computer before the heat death of the universe. The result will be that we end up with something about as safe as C is currently - because CPUs are fundamentally unsafe and we need them to work somehow. Rus…
> when you start using rust in the real world to get real work done a lot of the promises that were made about safety have to be dropped because you need to boot your computer before the heat death of the universe.
Safe rust isn't slow like Python, Go or Fil-C. It gets compiled to normal native code just like C and C++. It generally runs just as fast as C. At least, almost all the time. Arrays have runtime bounds checks. And ... thats about it.
> The result will be that we end up with something about as safe as C is currently - because CPUs are fundamentally unsafe and we need them to work somehow.
Nah. Most rust is safe rust. Even in the kernel, not much code actually interacts directly with raw hardware. The argument in favour of moving to rust isn't that it will remove 100% of memory safety bugs. Just that it'll hopefully remove most of them.