Comment by marhee

2 days ago

> The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C .... Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes.

What's the reach here of linters/address san/valgrind?

Or a linter written specifically for the linux kernel? Require (error-path) tests? It feels excessive to plug another language if these are the main arguments? Are there any other arguments for using Rust?

And even without any extra tools to guard against common mistakes, how much effort is solving those bug fixes anyway? Is it an order of magnitude larger than the cognitive load of learning a (not so easy!) language and context-switching continuously between them?

You can't valgrind kernel space

Linters might be helpful, but I don't remember there being good free ones

The problem here is simple: C is "too simple" for its own good and it puts undue cognitive burden on developers

And those who reply with "skill issue" are the first to lose a finger on it

  • > You can't valgrind kernel space > Linters might be helpful, but I don't remember there being good free ones

    I should have Googled:

    https://www.kernel.org/doc/html/latest/dev-tools/

    So many tools here. Hard to believe these cannot come close to what Rust provides (if you put in the effort).

    • Rust forces you to encode much more explicitly information about lifetimes and ownership into the code. Tools can only do so much without additional information.

    • Those solve a bunch of problems and can avoid a lot of issues if used properly, but it's time-consuming and cumbersome to say the least. Nowhere near as seamless or holistic as what Rust has to offer.

      3 replies →