Hacker News Reader

Comment by simias | Hacker News Reader

I understand your concern and I would definitely feel the same if some language I wasn't familiar with was suddenly introduced in the kernel. But at the same time as a big Rust enthusiast I think it's really a good idea in the long run: C is going nowhere but it's really dated, design-wise. When you've tasted the sweet nectar of type inference, strong typing, union types and of course the safety of the borrow checker, returning to C feels like banging rocks together.

The main drawback of Rust here I think is the longer compile times (I dread to imagine how long a fully Rustified kernel would take to build) and a generally more complex, but also more expressive language.

More generally I trust the kernel maintainers not to succumb to the hype and overdo it. People who still exchange patchsets over mailing lists are probably unlikely to be blinded by shiny things.

View on HN

From the perspective of people who don't know Rust, it's not a sweet nectar, but a suspicious murky liquid.

From the perspective of people who don't like aspects of Rust, it's a yucky goo.

This is _not_ like with C. Few people are enamored with C, but - the language itself is relatively simple (Duff's device notwithstanding...), so in my analogy it's like water. You may not adore it, but you can see through it, and you'll be ok with gulping it down to quench your thirst.

> From the perspective of people who don't like aspects of Rust, it's a yucky goo. > This is _not_ like with C

I beg to differ. This is exactly how I feel about C. C is the language that's confusing as hell to read for anything other than really simple use cases AND makes it super easy for me to shoot myself in the foot.

C is what you program is what you get. and i think that is pretty important.

C is what you program is what you might get.

Know thy standard and thy compiler optmizations, least you be surprised by the outcome.

This is true for any programming language. The problem is being aware of what you really wrote

No, you are wrong. C++ is one example. I've been using that language now for about 20 years and I still don't use all of its features. It is possible to write code in that language that you assume will work a certain way but then in practice it does a lot of things you didn't think you signed up for. Recently I started using STL more, after having stayed away from it for most of my career, and the performance of my application went out the window, and I had to override all memory allocation related functions to fully understand where the problem was coming from. It's easy to use the STL and make assumptions about performance, then find out later you get a lot of issues that come with it that you never signed up for. And that is why I don't want rust in the kernel. If a language does a lot of stuff for you, there will be a price to pay.

> It is possible to write code in that language that you assume will work a certain way but then in practice it does a lot of things you didn't think you signed up for

This is also possible for C. Most commonly around Undefined Behaviour. C only does what you expect it to do if you know the C spec inside out. Rust can have confusing behaviour too, but it is generally much better in this regard than C or C++.

You may find it easier to reason about C than Rust, but that's only because you know C better. I find it much easier to reason about Rust.

With modern compilers, there is no such thing as what you program is what you get.

As long as you stay away from compiler-dependent, platform-dependent, and/or undefined behaviour, you should be fine. Main problem is that a surprising ab´mount of "looks normal" code is actually UB.

You would be "fine", but the compiler will optimize away alot of your code, and will rearrange a lot of the rest. I wasn't even talking about platform-dependent or undefined behavior.

> Few people are enamored with C, but - the language itself is relatively simple

if you don't use pointers, yeah. but like you can't built anything useful without pointers.

if you do not understand pointers and cannot work with them, you probably should not be a software engineer.

I'm not sure that it's the concept of pointers that make C code harder to maintain than other languages. Lots of languages have pointers, including Rust.

It's a question of whether unguarded pointers (and a lack of language features that keep pointer math from devolving into an unreadable mess) are good to have in areas where pointer errors can result in critical bugs. We started discouraging goto statements not because developers didn't understand them, but because they did understand them, and they understood that the tools you use influence the type of code you write. And Rust doesn't even really get rid of pointers, it just adds rules around them.

We all accept some degree of abstraction/safety tradeoff, otherwise we'd program in lower-level languages than C that are even simpler and even easier to understand. C does introduce a lot of complexity over more primitive assembly languages. And Rust introduces a lot of complexity over C.

Different people pick different points where they think the tradeoffs are optimized. But we have a pretty large amount of data suggesting that even <quote>good</quote> programmers in industry make pointer errors in C. So it's pretty obviously not lack of understanding that's causing these issues, it's that unrestricted memory access and pointer math is inherently error-prone. Whether it's SO error-prone that's it's worth introducing a much more complicated, rigid language into the kernel is left as an exercise for the reader. There is a downside to introducing more complexity here, all abstractions have downsides.

But it's real dismissive to say that if everyone understood C pointers then their code wouldn't ever devolve into an unreadable mess. I just don't think that's an opinion that can be backed up by any real evidence, pretty much every org struggles to some extent with writing secure C code. And we have a lot of experience in the field of software engineering that should have taught us by now that sometimes unreadable code is the result of language affordances and patterns.

Also there are many different ways to undestand and use pointers; there are many many programmers that are really good at using pointers and are able to engineer essentially safe architechtures, but many of those very good programmers would come up with incompatible architectures around pointer usage.

My wild guess is that most "simple" pointer errors (use-after-free, double-free, unintentionally using unitialized memory, ...) happens at interfaces where there isn't perfect comunication about what component is responsible for keeping track of each task.

Yeah, I think about a very offhand comment that Carmack made once that ended up resonating with me a lot, even though I don't think it's universally across the entire board true:

> "Most bugs are a result of the execution state not being exactly what you think it is."

There is an aspect of language design that is about making it hard to be surprised by things. And I vaguely suspect that a lot of pointer errors fall into this category; people assume something is being freed, they assume that a subroutine is cleaning up after itself or that it's not manipulating something, or that it doesn't need to call some setup method before it's run. These are boundary errors between interfaces where allowing users to (inadvertently) mask what is happening can lead to logic that feels very convoluted and hard to follow, and can also lead to simple errors around just forgetting to do stuff.

I wouldn't call that Carmack quote a mantra, I'm not saying it explains all programming (or that all architectural restrictions are good), it's just a lens that I keep coming back to when I think about language design and architecture; there's a real tradeoff in removing flexibility, but there is also a huge amount of value in systems/patterns that make it very hard to bury relevant information. And if a language can auto-surface some of those problems, that can lead to cleaner code.

It depends what level you mean. Understanding and using pointers on basic way is simple. Understanding pointer provenance, aliasing rules, etc. are a completely different level and people not very familiar with the spec (so almost everyone) do not understand a lot about pointers. http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p1434r0....

> The main drawback of Rust here I think is the longer compile times

The time scales with the compiled unit size. If you're compiling drivers/modules, they're going to be fairly small and not much slower than C.

I think type inference is much more important for people that used dynamically typed languages instead of C devs. You could argue that it is also much more important for Rust.

the point is that you still need to know what you are doing. rust won’t change that. C is everywhere, and that is not going to change anytime soon. your time is better spent understanding more of the kernel instead of learning another tool set.

one of the biggest hurdles for me was the DTB declarative language. that was the most stupid idea ever to invent that and i lost 100s of hours trying to get my DTB files right for my hardware. so you can understand i don’t want more hipster shit to deal with.

You need to know less about what you're doing with Rust at any given time versus C, for the programmer.

Also at this point, Rust isn't "hipster shit". You're just not familiar with it, and that's fine. But it's in wide use now and proven to solve major classes of recurring issues.

i’ve looked at it briefly. i do not need or want it, and that is fine. what is important, is to keep the kernel tree simple and understandable. that means minimizing the number of tools and languages involved. which means not introducing rust.

> keep it simple and understandable

Yes. Rust helps with that because as a language it simplifies avoiding huge classes of vulnerabilities.

Rust simplifies it for the developers by moving part of the mental model of the developer into the compiler.

i don’t care about vulnerabilities. it is very annoying that everyone assumes that linux is only used for applications where security matters. plenty of devices using linux do not need to be secure and forcing rust onto the entire linux kernel community because of a vulnerability argument is stupid and will only make it harder for people to use linux in a project.

This is just absurd. It's like arguing against seatbelts as a default in cars because you might sit in your driveway most of the time.

Most Linux installations are cloud servers. So yes, Linux really needs to be secure.

i think that has changed over the past 20 years. linux is now everywhere and not just on servers in data centers. and this requirement is not a valid reason to force rust onto all device creators who choose linux.

Assuming anything new is bad because of a bad experience seems like a poor lesson to take.

Of course you need to know what you are doing still, but pretending humans don't make mistakes even when they know what they are doing is ignoring reality.

As a counterpoint security in e.g. Bluetooth has been an ongoing problem and even "mature" code like ext4 has recurring problems. Somehow I doubt the problem is that the people involved are not smart enough or trying hard enough. Maybe it's worth revisiting what tools we use.

there are many situations where security does not matter. so that is not a reason to force rust into the code base. not everyone is working on a device that needs to be secure.

> not everyone is working on a device that needs to be secure.

And those drivers can continue to be written in C. Rust is merely an option.

i need to be able to read and understand any driver’s source code without having to learn rust.

So the whole kernel should be beholden to you as the minimum viable target then? I hope you realize how self centered that outlook is.

The rubric for decision making in Linux kernel driver development is not "what HN user b20000 thinks they need", as far as I am aware.

this is not about me. it is about keeping the kernel tree reasonably accessible for small startups and device creators who do not have the funding of FAANGs and cannot afford to take on more complexity on top of something that is already very complex.

Anyone who values simplicity over security in the most used kernel in the world, has their priorities in the wrong place.

Have you tried reading or writing any Rust?

I have, and it was the most frustrating language I've ever tried. You sit there staring at the code wondering what's wrong with the variable you created until you Google it and find out it's a certain type that you never heard of. It's ridiculous.

I'm sure it gets better as you memorize the millions of different types, but what benefit do you get from all this pain?

I also think it's just a boy's club at this point. Big pipe dreams of rewriting all the C++ and C code is all we here about. It's not going to happen. The language is too f*k*g hard to learn so no one will. It's like trying to make everything in Haskell, c'mon, get real.

Someone had to say it...

How do you mean, "memorize the millions of different types" and "You sit there staring at the code wondering what's wrong with the variable you created until you Google it and find out it's a certain type that you never heard of"?

I don't think I've experienced this in any language, even ones with the most expressive type systems. More typing is better, as far as I have experienced, and as far as I have heard from people who take it up in their projects.

The compiler will tell you exactly what goes wrong if you pass the wrong type. If you mean that type inference was confusing, it's the same as `auto` in C++. Except the Rust compiler does an enormous amount of handholding with errors, often showing you exactly how to correct your code.

why is this voted down? can’t we have a conversation and hear some other opinions?

>> I also think it's just a boy's club at this point.

Probably mostly because of that.

Not that the other points are necessarily easy to follow since they're not well explained. If knowledge of why some type was hard to know or had to be googled (or for example noting what one of those types is) was presented, then people might have been able to respond to those points.

Instead it reads as "it's hard, I used it and it's hard, and I had to do some stuff I didn't like, and so my impression is it's just a bunch of people faffing off and it's too hard to take seriously", which isn't really useful for a discussion, and additionally is dismissive. Every one of the criticisms presented could be said about C without any change because no actual concrete details are provided.

It's not like Rust is perfect, there are many valid criticisms of it that have real examples and make useful points. Those comments probably deserve your defense more than this one.

> your time is better spent understanding more of the kernel instead of learning another tool set

No matter your skill level, that won't stop you from committing memory-safety mistakes that may lurk for years until they suddenly result in a catastrophic failure. Evidence for that is abundant.

What is DTB??

A file format to describe device trees, which describe the HW attached to the system. Mainly used on !x86 arches, as an alternative to ACPI-style autodiscovery:

https://en.wikipedia.org/wiki/Devicetree

I laughed out loud reading at his devicetree frustration, because while it's pretty gross to work with at times, at least it's not ACPI!

You always need to know what you're doing, but Rust lets you encode more of what you mean in the code and the compiler checks that you're not violating your own invariants. That's the killer feature for me. I feel like I'm working with the compiler, not against it.

Sometimes I feel like C's compiler is almost adversarial, going out of its way to find small mistakes in my code and have them blow in my face at runtime instead of notifying me. I understand why it works that way of course, but usually when my Rust code compiles, it works. I can't say as much for my C code, despite nearly 20 years of practice.

I do share some of your frustrations with the DTB thing, I'm not a fan of it either, although something like that was needed and I'm sure any alternative would have its haters.

Reply on news.ycombinator.com