6 ms·

>- I think it would increase the general productivity in kernel development. A better kernel helps everyone out. Don't you think the massive increase in compil

by caslon 6y ago

>- I think it would increase the general productivity in kernel development. A better kernel helps everyone out. Don't you think the massive increase in compilation time would negate any productivity gains and probably decrease productivity overall?

gpm 6y ago
No, because - I don't think it will be massive. - I especially don't think it will be that large for incremental builds, which is the main thing that matters. (But I'm not involved in this project, so I don't actually know how incremental the builds are...) - My experience is that the vast majority of programming time is spent fixing mistakes, not compiling. Rust reduces the amount of time spent fixing mistakes a lot more than it increases time spent compiling. - Rust moves many errors early in the compilation process (instead of when you try and test your code), which reduces iteration time instead of increasing it. I'm not involved in this project, but I imagine it's at a point where you could get some numbers for the fixed overhead that adding rust adds to the compile times. I'd be interested in seeing those numbers.
staticassertion 6y ago
Have you compiled the Linux kernel before? I doubt Rust will be the bottleneck, it's a massive project - a tiny fraction being in Rust will be a blip.
- caslon 6y ago
  Pretty frequently, yes. It doesn't take that long on modern, moderately-powered devices. Even when I was using a mid-tier device from a decade ago, compilation time was still around half an hour, which was less than most Rust projects I've encountered are on modern and reasonably high-end hardware, despite doing much more and being much larger.
  - staticassertion 6y ago
    Yep, that sounds exactly right to me - about 30 minutes on older hardware. That's very odd to me that you have 30 minute rust build times - as someone who works on a rust project professionally, with 10KLOC, that isn't my experience at all. If Rust gets into the kernel I would expect it to account for <1% of the code, so even if it were 100x slower to compile, which it isn't, I don't see it having an impact.
    - bluecalm 6y ago
      Man, 10KLOC is a very small project. Obviously it compiles quickly. Linux kernel is almost 30 million lines of code.
      - staticassertion 6y ago
        Yes... exactly. The Linux Kernel is 30 million lines of code - so how exactly will some minimiscule-by-comparison amount of Rust code slow down compile times considerably?
        bluecalm 6y ago
        If it's always going to be miniscule then why bother? If it has potential to grow to something not miniscule then it's important to it compiles quickly.
        staticassertion 6y ago
        1. Even if we start today, and all new code is written in Rust, it will be years before Rust has an impact on compile time. 2. A relatively small portion of code can account for the majority of exploited vulnerabilities. 3. Nothing about Rust is fundamentally slow with regards to compile times. There's plenty of time to work on it, and we've already seen significant efforts make headway. Compile times are a nonissue in any practical sense for this work.
    - himujjal 6y ago
      I wrote 10kLOC last week. Most of the code didn't require much extra thinking, it was mostly a translation of an old TypeScript project to Zig. But measuring compile times with 10kLOC is really not a good argument.
  - jstrong 6y ago
    I've been coding predominantly in rust since 2018 and have never encountered a build time > 10min.
    - LandR 6y ago
      Worked at a place where our c# build times for a large project, many millions of loc, were 40 mins or so.
steveklabnik 6y ago
"Productivity" is notoriously hard to measure in software. While slow compile times may slow you down, and hence reduce your productivity, if the compiler prevents hard to fix bugs, it still may increase your overall productivity. Consider things like https://hacks.mozilla.org/2021/04/eliminating-data-races-in-firefox-a-technical-report/ https://hacks.mozilla.org/2021/04/eliminating-data-races-in-... > Overall Rust appears to be fulfilling one of its original design goals: allowing us to write more concurrent code safely. Both WebRender and Stylo are very large and pervasively multi-threaded, but have had minimal threading issues. What issues we did find were mistakes in the implementations of low-level and explicitly unsafe multithreading abstractions — and those mistakes were simple to fix. > > This is in contrast to many of our C++ races, which often involved things being randomly accessed on different threads with unclear semantics, necessitating non-trivial refactorings of the code. Maybe the C++ was faster to compile, but in the end, fixing these issues took more time. There were more of them, and they were harder to track down. Nobody truly knows the answers to these questions in the general case yet, of course. My point is just that "slow compile == bad productivity" is not inherently true. Faster compile times are, of course, always desired no matter what.
- diragon 6y ago
  > "Productivity" is notoriously hard to measure in software. We can look at history and results. In these terms, C (and perhaps C++ to some extent) is, I believe, the only productive programming language for making the low level parts of non-experimental kernels. As far as it can be publically measured, Rust so far has proven itself for application programming in a certain niche and not much more. It would be cool if it could prove itself in kernel space too -- we certainly need less system crashes caused by bad kernel-level code. Curiously though, it has been a very long time since I've last bumped into such a thing in Linux. This makes me suspect that Rust is trying to fix a problem here that's already been fixed in another way. As for ease of coding, C seems like a massively easier language to learn than Rust. But I might be wrong there. Any data about that, I wonder?
  - steveklabnik 6y ago
    Yes, that is true. But the only way to get that data is to do it. This work is one part of doing that. Someone has to be first :) (There are of course a ton of kernel-level things in Rust that don't pass the "non-experimental" bar for various people. As always, depends on exactly what you mean.) > Any data about that, I wonder? Possibly one of the only things harder to measure than productivity is ease of learning, haha! I had programmed in C for decades before Rust even existed. We do have a lot of people who say that they think Rust was easier to learn for them than C was. And of course many who believe the opposite. Not sure anything is conclusive in any direction. For example, it's quite possible that some people find C easier, and some people find Rust easier, and there will never be a clear winner. Time will tell.
E14n 6y ago
If you are talking speed to production ready code then rust is really productive. The rust tooling picks up a lot of errors and leads you to spending more time fixing coding issues rather then compile to test your code.

by caslon 6y ago

gpm 6y ago

No, because - I don't think it will be massive. - I especially don't think it will be that large for incremental builds, which is the main thing that matters. (But I'm not involved in this project, so I don't actually know how incremental the builds are...) - My experience is that the vast majority of programming time is spent fixing mistakes, not compiling. Rust reduces the amount of time spent fixing mistakes a lot more than it increases time spent compiling. - Rust moves many errors early in the compilation process (instead of when you try and test your code), which reduces iteration time instead of increasing it. I'm not involved in this project, but I imagine it's at a point where you could get some numbers for the fixed overhead that adding rust adds to the compile times. I'd be interested in seeing those numbers.

staticassertion 6y ago

Have you compiled the Linux kernel before? I doubt Rust will be the bottleneck, it's a massive project - a tiny fraction being in Rust will be a blip.

caslon 6y ago
Pretty frequently, yes. It doesn't take that long on modern, moderately-powered devices. Even when I was using a mid-tier device from a decade ago, compilation time was still around half an hour, which was less than most Rust projects I've encountered are on modern and reasonably high-end hardware, despite doing much more and being much larger.
- staticassertion 6y ago
  Yep, that sounds exactly right to me - about 30 minutes on older hardware. That's very odd to me that you have 30 minute rust build times - as someone who works on a rust project professionally, with 10KLOC, that isn't my experience at all. If Rust gets into the kernel I would expect it to account for <1% of the code, so even if it were 100x slower to compile, which it isn't, I don't see it having an impact.
  - bluecalm 6y ago
    Man, 10KLOC is a very small project. Obviously it compiles quickly. Linux kernel is almost 30 million lines of code.
    - staticassertion 6y ago
      Yes... exactly. The Linux Kernel is 30 million lines of code - so how exactly will some minimiscule-by-comparison amount of Rust code slow down compile times considerably?
      - bluecalm 6y ago
        If it's always going to be miniscule then why bother? If it has potential to grow to something not miniscule then it's important to it compiles quickly.
        staticassertion 6y ago
        1. Even if we start today, and all new code is written in Rust, it will be years before Rust has an impact on compile time. 2. A relatively small portion of code can account for the majority of exploited vulnerabilities. 3. Nothing about Rust is fundamentally slow with regards to compile times. There's plenty of time to work on it, and we've already seen significant efforts make headway. Compile times are a nonissue in any practical sense for this work.
  - himujjal 6y ago
    I wrote 10kLOC last week. Most of the code didn't require much extra thinking, it was mostly a translation of an old TypeScript project to Zig. But measuring compile times with 10kLOC is really not a good argument.
- jstrong 6y ago
  I've been coding predominantly in rust since 2018 and have never encountered a build time > 10min.
  - LandR 6y ago
    Worked at a place where our c# build times for a large project, many millions of loc, were 40 mins or so.

steveklabnik 6y ago

"Productivity" is notoriously hard to measure in software. While slow compile times may slow you down, and hence reduce your productivity, if the compiler prevents hard to fix bugs, it still may increase your overall productivity. Consider things like https://hacks.mozilla.org/2021/04/eliminating-data-races-in-firefox-a-technical-report/ https://hacks.mozilla.org/2021/04/eliminating-data-races-in-... > Overall Rust appears to be fulfilling one of its original design goals: allowing us to write more concurrent code safely. Both WebRender and Stylo are very large and pervasively multi-threaded, but have had minimal threading issues. What issues we did find were mistakes in the implementations of low-level and explicitly unsafe multithreading abstractions — and those mistakes were simple to fix. > > This is in contrast to many of our C++ races, which often involved things being randomly accessed on different threads with unclear semantics, necessitating non-trivial refactorings of the code. Maybe the C++ was faster to compile, but in the end, fixing these issues took more time. There were more of them, and they were harder to track down. Nobody truly knows the answers to these questions in the general case yet, of course. My point is just that "slow compile == bad productivity" is not inherently true. Faster compile times are, of course, always desired no matter what.

diragon 6y ago
> "Productivity" is notoriously hard to measure in software. We can look at history and results. In these terms, C (and perhaps C++ to some extent) is, I believe, the only productive programming language for making the low level parts of non-experimental kernels. As far as it can be publically measured, Rust so far has proven itself for application programming in a certain niche and not much more. It would be cool if it could prove itself in kernel space too -- we certainly need less system crashes caused by bad kernel-level code. Curiously though, it has been a very long time since I've last bumped into such a thing in Linux. This makes me suspect that Rust is trying to fix a problem here that's already been fixed in another way. As for ease of coding, C seems like a massively easier language to learn than Rust. But I might be wrong there. Any data about that, I wonder?
- steveklabnik 6y ago
  Yes, that is true. But the only way to get that data is to do it. This work is one part of doing that. Someone has to be first :) (There are of course a ton of kernel-level things in Rust that don't pass the "non-experimental" bar for various people. As always, depends on exactly what you mean.) > Any data about that, I wonder? Possibly one of the only things harder to measure than productivity is ease of learning, haha! I had programmed in C for decades before Rust even existed. We do have a lot of people who say that they think Rust was easier to learn for them than C was. And of course many who believe the opposite. Not sure anything is conclusive in any direction. For example, it's quite possible that some people find C easier, and some people find Rust easier, and there will never be a clear winner. Time will tell.

E14n 6y ago

If you are talking speed to production ready code then rust is really productive. The rust tooling picks up a lot of errors and leads you to spending more time fixing coding issues rather then compile to test your code.