5 ms·
Imagine this: we have a group of friends and we’re having a good time. We all speak English. One or two guys invite some people who are always speaking in Kling
by matt3210 2y ago
Imagine this: we have a group of friends and we’re having a good time. We all speak English. One or two guys invite some people who are always speaking in Klingon. They invite more and now a large amount of the group wants to have equal support in d&d and other activities for Klingon. They insist it’s a better language when it’s only just a different language, not better or worse. The English speakers are trying to stop the Klingon speakers from changing their group to something new that they don’t like (and not provably better).
Rust is Klingon. C is working fine and is the language everyone is already familiar with. If Rust was actually better, it would flow into the ground organically.
Being technically more memory safe doesn’t make people like it more. Proper tooling with C can prevent memory issues, taking away the main argument for rust.
In the end we don’t need any more of a reason to stop rust other than “we don’t like rust”.
- perching_aix 2y ago> If Rust was actually better, it would flow into the ground organically. What would Rust flowing into the Linux kernel organically look like in your opinion? On a similar note, I work in a non-English speaking country, but have developed a real bad habit of sticking to English when it comes to technical discussions (work or non-work). Mind you, this is an international company we work at, proficiency in English is expected (and often lackluster). My colleagues don't appreciate this, and will poke fun at it from time to time. They're convinced I'm being obnoxious on purpose, despite me just spending 90% of my day interacting with English in English. It is only natural then that I keep thinking about things in English. What you'll discover is that these colleagues of mine have two things in common: they're not anywhere nearly as immersed and proficient in English as I am despite working here for a decade, and that they're a bit of an old-timer jackass types. This was not metaphor.
- matt3210 2y agoI don’t know what it looks like, but it’s definitely not forcing people to accept it. Rust right now just isn’t in a form that some (I personally think most) people can accept. Maybe it’s just that it’s so not-c-like. … given your language examples, maybe the main issue is just that rust is just so different. I personally find the rust language to be non intuitive… but what’s intuitive for me is heavily informed by c/c++ or python
- perching_aix 2y agoWhat I was kind of getting at is that I cannot imagine a new language being introduced without friction, regardless of how organically that happens, and that you probably don't either. Obviously, there's room for a middle ground here, where we recognize that these are absolutes, and so we start debating whether what would be a less friction inducing way. This could then split into whether it's Rust the language that's causing the friction that exists, or the community on either side. Personally, I don't see a less friction inducing way being possible, and according to the people involved, it's a mix of both the language and the communities that this friction is the way it is - and I find that to be pretty believable, honestly. Not only that, and we're getting to very philosophical heights here I admit, but I think this is a pervasive issue with how people usually reason about hardships: that there must always exist a solution to problems. I don't think that's true. I think that things sometimes suck, and there's no way around them, you can only balance between the ways they suck (dilemma instead of a problem). I further think it is all too often this reach-for-a-solution is exploited in rhetoric (and of course, it wouldn't be life without examples for the exact opposite too). It's also a bit like being down. Sometimes it's justified, and there's no need to "correct" or change it.
- kelnos 2y ago> it’s definitely not forcing people to accept it Wait, you mean you've worked on projects where you've achieved unanimous agreement on any large technical decision, ever? No, sometimes people need to be forced to accept change. The whole "disagree and commit" thing. Humans are strange creatures; we often resist change for the sake of resisting change, regardless of whether or not the change is good for us. When it comes to the Linux kernel, what Torvalds says is law. He certainly isn't going to go against what many/most of his trusted maintainers want, but ultimately he's going to decide what's best for the project, based on his own reasoning, and the choices are to get on board, or find another project to work on. It wouldn't be the first time he's "forced" people to accept something that he's decided on.
- shakow 2y ago> but it’s definitely not forcing people to accept it. No one is forced to accept it. The big whiny outbursts from the old guard was when the RfL guys asked them to specify their implementations; they were never asked to touch a LoC of Rust even with a 10ft pole.
- hollerith 2y ago[flagged]
- sunshowers 2y ago> Proper tooling with C can prevent memory issues, taking away the main argument for rust. This is not true, despite decades of research and billions of dollars poured into static analysis of C programs. Rust solves this by making programmers put pervasive annotations into their code, and even more importantly by making programmers like the fact that they have to put pervasive annotations into their code. Rust today, without additional tooling, delivers a better memory safety story than C static analysis researchers could ever dream about.
- accelbred 2y agoThis is false; with formal analysis tools like CBMC, you can prove the memory safety properties of your C code. You can even statically prove lack of integer overflows and that asserts are unreachable. I'll agree this is uncommon in general, but CBMC is used for various C codebases where I work. Though this tooling is also available for Rust with Kani.
- kelnos 2y agoIs CBMC usable, directly, on any project? Or do you need to write your code in a certain way, using certain patterns, etc.? Or does the CBMC tooling need to be taught various things about how memory management works in your project? Regardless, the fact that it's not used regularly/routinely with the Linux kernel (or any project that I'm aware of) suggests that it's either not suitable, doesn't catch enough issues to be worth the effort, or is just such a pain to deal with that no one has the patience to put up with it. Rust gives you much (sure, not all) of what CBMC provides, in the compiler. That is a huge win, IMO.
- pdimitar 2y agoYet it's still not used in most C codebases. Where was it for Heartbleed? We all understand that things can be done better. The problem is that they often are not. Rust and other tools help by not giving people the choice to do sloppy work at all. History has proven many times that defaults matter.
- 2y ago
- kstrauser 2y ago> Proper tooling with C can prevent memory issues So far this year, the Linux kernel has 849 overflow and memory corruption CVEs: https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm... What is your advice to the Linux kernel developers who, by your logic, are not using proper tooling? I’m not willing to tell them they’re doing it wrong because they’re experts in a very technically challenging field I don’t know much about. What is it you think they’re doing wrong, given your experience?
- shepherdjerred 2y agoMy favorite illustration of this is Xe’s blog: https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024-9632/ https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024...
- kstrauser 2y agoFor sure. That was adapted from https://theonion.com/no-way-to-prevent-this-says-only-nation-where-this-r-1819576527/ https://theonion.com/no-way-to-prevent-this-says-only-nation... but still rings true. If only there were someone to avoid these huge arenas of error-prone, demonstrably impossible to write correctly conditions! Rust, Zig, D, OCaml, Erlang, Haskell, programmers look at each other disappointedly
- pjmlp 2y agoIt is even worse than that, paraphrasing you, ESPOL, NEWP, PL/I, PL/S, PL.8, Mesa, Modula-2, Ada, Object Pascal, programmers look at each other disappointedly Even taking into consideration the systems programming languages until the 1980's, the list isn't exhaustive.
- kstrauser 2y agoOh sure! C/C++ are the only current major languages that spring to mind that make it so easy to shoot your foot clean off. Assembler, I guess, except it’s not nearly so widely used and everyone knows what they’re getting into with it.
- prmoustache 2y agoYour analogy would be right if talking english would make people statistically vert likely to randomly open doors or windows and shout at everyone in the street the code of their safe and crash their cars into the building while the klingon speakers would not exhibit that behavior.
- BrouteMinou 2y agoNot the main argument, The only argument for Rust. The only single one argument for Rust.
- bennettnate5 2y agoThere are actually quite a few nice features that go beyond memory safety: - Type-safe generics (sorry C, `void*` doesn't count) - Compiler errors that try to give you the root reason why your code isn't compiling and a solution to the problem - Procedural macros to automatically generate boilerplate code for arbitrary structs/enums - Solid package management tooling built into the workflow that doesn't rely on what Linux distro you're running - consistent and easy-to-use macros for writing code meant to be used across OSs or architectures. I've written system-level packages compatible with Windows/Linux/MacOS/Every BSD flavor/Solaris with relative ease.
- BlueTemplar 2y agoThat their tooling (and community, starting from teaching examples) seems to rely on Github so much is worse than dealing with a diversity of distributions.
- shepherdjerred 2y ago> If Rust was actually better, it would flow into the ground organically. This is plainly untrue. People don’t like change even if change is for the better. I’m not saying Rust is better than C, only that you’re completely incorrect about better things winning.
- xena 2y ago> Proper tooling with C can prevent memory issue Please tell me what I install and use to prevent this issue: https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024-5535/ https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024... I just want to know what I've been missing. This is a genuine question.
- epidemian 2y ago> If Rust was actually better, it would flow into the ground organically. Isn't that basically what's already happened with Asahi Linux?
- kelnos 2y ago> Proper tooling with C can prevent memory issues Statements like these make me not take people seriously. The state of the art in tooling for C to catch memory issues is miles ahead of what it used to be. But they won't catch everything, not by a long shot, especially when you often have to teach the tools how memory is managed in whatever library you're using that isn't just simple malloc()/free(). If the compiler for my language of choice can just do all this for me, and fail to compile my code when these issues might exist in my code, that's amazing. I don't want a language that lets me do broken things, and requires me to run an extra linter or tool or whatever to help me figure out what I've done wrong later.
- pjmlp 2y agoApparently 60 years isn't enough to learn how to use proper tooling.
- Ygg2 2y ago- A Hundred more years ought to do the trick. Once we train AI to do it. - What data will you feed it? - Current C codebases and best practices. - OOOF.
- pjmlp 2y agoWhen AI gets advanced enough, compilers will be gone, there won't be a need for C anyway. Just like Assembly got reduced to a very niche use case, after optimizing compilers got better than much humans at handling Assembly code manually. Technically those will be AI/ML Compilers, but I digress. It is anyway a win regarding C and its superset derivatives.
- Ygg2 2y ago> If Rust was actually better, it would flow into the ground organically. Yeah, and languages like Ada are widely used everywhere. And no one ever writes code in Cobol or JavaScript, since it was that bad. I mean, when seatbelts were introduced, everyone[1] flocked to show how cool and safe they were. It's not like government had to mandate it from above, right? [1] (it's a subtle joke only 2% bought Ford's cars with seatbelts) https://web.archive.org/web/20201130151600/https://www.history.com/this-day-in-history/unsafe-at-any-speed-hits-bookstores https://web.archive.org/web/20201130151600/https://www.histo...
- pdimitar 2y ago> If Rust was actually better, it would flow into the ground organically. Rust is flowing into the ground organically just fine, but in the kernel dev area people are actively stopping it. So the "organic" part is interfered with. Part of the time for good reasons, absolutely! But the rest of the cases do give off the "get off my lawn" vibe to me. A better analogy than yours would be "the new people came with a proposal for a new way to list and enforce the rules in the D&D group" IMO. Something that will improve the session but might still give you a culture shock of the new way of doing things. Seems like a more accurate analogy. > Being technically more memory safe doesn’t make people like it more. Microsoft and Google have stated that from 60% to 75% of all CVEs are memory-safety-based. Is that not good enough of a reason to fight against memory un-safety? Nobody is requiring you to "like" it -- more like "accept evidence backed with data by entities that work a lot with both C/C++ and Rust". > In the end we don’t need any more of a reason to stop rust other than “we don’t like rust”. That's not a merit-based or technical argument and such is not interesting. Why mention it? > Proper tooling with C can prevent memory issues, taking away the main argument for rust. Banning driving under the influence of alcohol can prevent numerous tragic car crashes. Worked beautifully, right?
- imtringued 2y ago>Proper tooling with C can prevent memory issues, taking away the main argument for rust. The only way is to compile everything with -fsanitize=undefined,address,float-divide-by-zero,unsigned-integer-overflow -fsanitize-minimal-runtime. Anyone who uses less than this is reckless.