Hacker News Reader

Comment by matt3210 | Hacker News Reader

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”.

View on HN

> 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.

I 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

What 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.

> 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.

> 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.

> 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.

This 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.

Is 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.

Yet 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.

That’s the crux of it. I think I can write safe C. So do many other people who, surely like me, cannot. I know I’ve written safe Rust because I had to fix my code until it was able to compile.

I think the issue with such formal analysis tools is that in order to make the analysis succeed you often end up writing code that doesn't look like normal C anymore and arguably at that point you're not writing C anymore.

---

As an aside, does CBMC check temporal memory safety and thread safety? It seems it checks for out-of-bound accesses, null pointer access and double-free, but I could not find a mention of use-after-free and data races.

CBMC is truly wonderful technology. Rust is still more powerful and easier to use at scale.

If your project has 100k lines of code, would you rather use CBMC or Rust? What about if your project has a million? 10 million? 100 million?

The fundamental issue is that SMT-based verification scales quite poorly. The optimal use of SMT-based verification is proving local properties of small chunks of code independently, and using the type system's encapsulation to scale up to global correctness.

> even more importantly by making programmers like the fact that they have to put pervasive annotations into their code

That’s the thing: many of us deeply dislike the annotations since they slow things down and look ugly.

Completely reasonable.

Many developers dislike doing all sorts of useful things, like writing documentation in general, or tests.

Rust is an upfront investment of time which pays back in later stages when you're not spending 10 hours hunting down issues with valgrind or trying to explain codebase-specific lifetime semantics to junior developers. Yes the initial development is "slower", but you can then do massive refactors without fear of breaking some subtle rule that will blow things up, because such rule-breaking would result in a failure to compile.

I must write code very differently than most writing the actual code is not what takes my time. Sure you feel that time, but it ends up being a pretty small percentage of mine.

So? I feel like that backs up my point. Sure it may slow down development but it encodes useful information for reading and understanding the code later on, and preventing the most pernicious sorts of bugs (data races, UB, memory unsafety) from creeping in in the first place - and thus less need to spend time doing non-development tasks later.

Yes, I am agreeing. I am saying, a lot of these affordances that enter code faster or terser are not where I spend my time. I spend my time on the things you are talking about.

Rust is a continuous additional investment of time which will need to happen when writing the code, changing the code, doing the massive refactorings you mention and last but not least when reading the code.

There are benefits to that investment, but likely only in specific kinds of software (such as browsers, kernels, etc) which are relentlessly attacked and for specific kinds of programmers that like to specify things in much detail and don’t mind the associated costs.

The friction comes from pushing Rust as a generic solution for most programmers. See the Rust in the backend efforts for the perfect example.

> 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.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?

My favorite illustration of this is Xe’s blog: https://xeiaso.net/shitposts/no-way-to-prevent-this/CVE-2024...

For sure. That was adapted from 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

It 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.

Oh 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.

> the Linux kernel has 849 overflow and memory corruption CVEs

4 years ago, they had 40 memory-corruption-related CVEs. Their actual vulnerability count hasn't increased by 2122% over 4 years – rather, they've become a CVE numbering authority and have started self-assigning CVEs even when there is no evidence of a vulnerability:

> Due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assigns CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team.

<https://lwn.net/ml/linux-kernel/2024021430-blanching-spotter...>

Having a huge number of self-issued CVEs is a policy decision on the part of the Kernel maintainers.

> 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.

> 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?

Your 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.

Apparently 60 years isn't enough to learn how to use proper tooling.

- 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.

When 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.

Maybe in the far, far future. The AI hallucinations, would turn optimizing compilers from "computer magic" to the "computer ultra nightmares" or maybe "My computer is having nightmares and I must scream".

That would give a new meaning to UB. :)

> 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.

> 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.histo...

> If Rust was actually better, it would flow into the ground organically.

Isn't that basically what's already happened with Asahi Linux?

> 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...

I just want to know what I've been missing. This is a genuine question.

>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.

Not the main argument, The only argument for Rust. The only single one argument for Rust.

There 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.

That their tooling (and community, starting from teaching examples) seems to rely on Github so much is worse than dealing with a diversity of distributions.

Reply on news.ycombinator.com