yeah like if only they had written AI in rust instead of python AI safety wouldn't be an issue
“Rust is safe” is not some kind of absolute guarantee of code safety
321–330 of 542 posts
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#322Earlier quoted context omitted.
Rust doesn't have an official `#[never_panic]` annotation, but there's a variety of approaches folks use. Static analysis (Clippy) can get you pretty far. My favorite trick is to link a no_std binary with no panic handler, and see if it has a linker error. No linker error = no calls to panic handler = no panics. Note that Rust is easier to work with than C here, because although the C-like API isn't shy about panicki…
> Static analysis (Clippy) can get you pretty far. What's funny about this is that (while it's true!) it's exactly the argument that Rustaceans tend to reject out of hand when the subject is hardening C code with analysis tools (or instrumentation gadgets like ASAN/MSAN/fuzzing, which get a lot of the same bile). In fact when used well, my feeling is that extra-language tooling has largely eliminated the practical sa…
The difference being that C is barely changed for the sake of backwards compatibility while the panicking in kernel space is a recognized problem with rust that is being actively worked on and will have a solution in the future.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#323Earlier quoted context omitted.
Just as many people have problems with this form of communication, many people find it hard to clearly express themselves in an environment where they're expected to put people's feelings above all else. What some might perceive as "hostile", others would simply call "honest". It's simply a matter of preference.
No, it’s not “simply a matter of preference” when it causes someone else to be in a hostile work environment. At that point, you’re affecting the lives of those around you. Sure, some people have medical conditions that might prevent them from seeing this, but even they put in an effort to be better. It stops being a “preference” when it actively hurts those around you. If you are an asshole, are known to be an assho…
>You’re free to work alone, but why make people around you miserable by having to deal with you? Go be an asshole to yourself and let everyone else work together.
You, and the billions of people using linux, are free to fork the code and exclude Linus completley.
>It’s shocking that advocating for safe and inclusive work environments
This isn't a "work enviroment" in the way you seem to be implying. The vast majority of people contributing to the kernel do not work for linux or Linus.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#324Earlier quoted context omitted.
Proof assistants, which I expect to eventually merge with programming languages, can be used to restrict the set of programs you write to those where you can statically prove all properties you expect the program to hold. It’s not much different from what diligent programmers have always done in their head (with, of course, much more room for error). The fact that arbitrary programs are undecidable is a red herring h…
"Undecidable" Is way too close to your day2day program than you think: https://en.wikipedia.org/wiki/Rice%27s_theorem I would like to learn otherwise, but even a React JS+HTML page is undecidable... its scope is limited by chrome V8 js engine (like a vm), but within that scope I don't think you can prove anything more. otherwise we could just make static analysis to check if it will leak passwords...
I’m not sure you understand Rice’s theorem correctly. It means that you can’t write an algorithm that takes an arbitrary program as input and tells you whether it fulfills a given nontrivial semantic property. But you can write an algorithm that can tell you for some subset of programs. So as a developer, if you restrict yourself to releasing programs for which the algorithm has halted and given you the desired answer, you are fine.
Depending on the semantic property to check for, writing such an algorithm isn’t trivial. But the Rust compiler for example does it for memory safety, for the subset of valid Rust programs that don’t use Unsafe.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#325Earlier quoted context omitted.
I mean if it is a cosmetic thing sure. If it has substantial meaning I would rather have that 5 ton robotic welding arm not move than have it move through my skill. It is sometimes acceptable to get wrong output. But is nearly always better to know it is wrong.
This sounds like the difference between "fault tolerant" and "fail safe". Fault tolerant - you get a fault, you keep moving. Fail safe - you fail, and thus all operations are stopped.
Failing may require triggering some actions actively. Going inert is not the right way in many cases. Some system absolutely require best efforts in the face of failure. A fire alarm in an otherwise secure and locked down facility may have to trigger the opening of door locks, for example.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#326Hahaha I did notice there's a lot of magical thinking amongst the rust people. Prediction: in time the same will happen to "rust in the kernel" as happened to "c++ in the kernel": Linus will forbid it not because of some intrinsic problem with the language, but because the culture of the community prevented them from understanding the kernel rules.
The kernel is not a magical beast. Other kernels have already been written in Rust and work fine. The ideas of Rust are not "magical thinking", they're based on fundamental mathematical principals that are irrelevant to language or tool.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#327Quoted post unavailable.
Because a gun that will disable the trigger to shoot yourself in the foot 1/10ths of the time is still worth it.
Rust is also WIP. The panic problem can still be solved.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#328Earlier quoted context omitted.
"Undecidable" Is way too close to your day2day program than you think: https://en.wikipedia.org/wiki/Rice%27s_theorem I would like to learn otherwise, but even a React JS+HTML page is undecidable... its scope is limited by chrome V8 js engine (like a vm), but within that scope I don't think you can prove anything more. otherwise we could just make static analysis to check if it will leak passwords...
I’m not sure you understand Rice’s theorem correctly. It means that you can’t write an algorithm that takes an arbitrary program as input and tells you whether it fulfills a given nontrivial semantic property. But you can write an algorithm that can tell you for some subset of programs. So as a developer, if you restrict yourself to releasing programs for which the algorithm has halted and given you the desired answe…
But isn't every program we write today (Rust, C++, Python, JS, etc.) raise up to the level of an "arbitrary program"? How do you find those "some subset of programs" that will halt by said algorithm?
The only sure way I can think of, is when you force your program to go through a more narrow non-turing algorithm. Like sending data through a network after Serialization. Where we could limit the De-Serialization process to be non Turing (json, yaml?).
Same for code, that uses non-turing API, like memory allocation in a dedicated per process space. Or rust "borrow" mechanics that the compiler enforces.
But my point is, everyday program are "arbitrary program" and not a red haring. Surly from the kernel perspective, which is Linus point imo.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#329Earlier quoted context omitted.
> Linus goes nuclear. And while his reasoning is sound, his argumentation cycles between threats, bad-faith arguments, and just plain old yelling. In my opinion, in the software world, there is a large number of people who are very convinced of their own correctness. When they do something wrong or are simply mistaken, a gentle correction doesn't work. Linus is probably used to dealing with these people. I'm not sayi…
> In my opinion, in the software world, there is a large number of people who are very convinced of their own correctness. When they do something wrong or are simply mistaken, a gentle correction doesn't work. Too bad there was no around to do that to Linus; maybe he'd finally realize that being an asshole is generally not a correct response.
I think this is generally correct. The argument is "Linux is extraordinarily successful" but I think the counter is just as powerful "How many great features have not been implemented, because people have avoided working on the kernel or simply burnt out?"
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#330Earlier quoted context omitted.
Okay, just to fact check this. I am a fan of Rust, but pretending there aren't these aggressive rust users is a bit putting your head in the sand. Like any language that has very cool features, there are people that take that tool as not a tool but a religion. You can even look in my comment history and see people arguing with me when I say I was a rust fan, but memory safety isn't a requirement in some areas of prog…
I, too, have not encountered these toxic Rust fanboys. I don't believe my head is in the sand. I do regularly see people degrading Rust and it's community, and so am convinced these toxic Rust fanboys are largely a myth based on uncharitable interpretations of otherwise reasonable statements. I think people often read "I advocate for the deprecation of all C/C++ codebases" into the statement "Rust is a 'safe' languag…
I've seen both sides of this, as a Rust user and as a Go user.
Rust users are generally friendly to one another, and to people who are interested in Rust. Hoever, some Rust users are toxic when talking to people outside the community or to people who disagree.
That's why a lot of us (in the Rust community) don't notice it; we spend most of the time inside our own community talking to each other and being friendly to each other.
This is a trait common to any bubble or insular community whether it be about politics, religion, economics, or whatever. It's fairly easy to recognize once you get in the habit of dis-identifying with your own side.
There's also a phenomenon in human psychology where we tend to forgive "our side's" misbehavior, presumably because it's in service to a higher ideal and therefore forgivable. It's the difference between "passionately spreading the good word" and "aggressive evangelism", two views of the same action. After learning about this I've even seen it in myself, though hopefully I've learned to counteract it a bit.
Note that this isn't unique to Rust, other languages have this too to an extent.
It's something I really hope we can leave behind, because it's hurting an otherwise beneficial message that Rust can bring a new tradeoff that is favorable for a lot of situations.