7 ms·

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 ti

• viraptor 5y ago
  > 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.
• b20000 5y ago
  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.
  • throwamon 5y ago
    > 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.
  • dagmx 5y ago
    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.
    • b20000 5y ago
      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.
      • dagmx 5y ago
        > 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.
        • b20000 5y ago
          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.
          • dagmx 5y ago
            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.
          • LtdJorge 5y ago
            Most Linux installations are cloud servers. So yes, Linux really needs to be secure.
  • Latty 5y ago
    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.
  • hedgehog 5y ago
    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.
    • b20000 5y ago
      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.
      • msbarnett 5y ago
        > 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.
        • b20000 5y ago
          i need to be able to read and understand any driver’s source code without having to learn rust.
          • dagmx 5y ago
            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.
          • msbarnett 5y ago
            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.
            • b20000 5y ago
              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.
  • duped 5y ago
    Have you tried reading or writing any Rust?
    • zerocount 5y ago
      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...
      • duped 5y ago
        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.
      • b20000 5y ago
        why is this voted down? can’t we have a conversation and hear some other opinions?
        • kbenson 5y ago
          >> 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.
  • JoelMcCracken 5y ago
    What is DTB??
    • xxpor 5y ago
      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 https://en.wikipedia.org/wiki/Devicetree
      • structural 5y ago
        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!
    • deleted 5y ago
      [deleted]
  • simias 5y ago
    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.
• einpoklum 5y ago
  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.
  • nicoburns 5y ago
    > 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.
    • b20000 5y ago
      C is what you program is what you get. and i think that is pretty important.
      • pjmlp 5y ago
        C is what you program is what you might get. Know thy standard and thy compiler optmizations, least you be surprised by the outcome.
      • kungito 5y ago
        This is true for any programming language. The problem is being aware of what you really wrote
        • b20000 5y ago
          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.
• raxxorrax 5y ago
  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.