4 ms·

I would not want someone writing kernel code who can't understand what the rest of it is doing.

by rjsw 4y ago

coldtea 4y ago
Who said those people will be writing kernel code? Rust for the Linux kernel is like 0.000001% of real life Rust use (which is not that big to begin with). And it wouldn't be used the main kernel for the most part anyways, mostly (if not exclusively) kernel drivers.
- rjsw 4y ago
  This thread is about a kernel DRM driver written in Rust, writing any DRM driver requires a lot of knowledge about how the rest of the DRM subsystem and the kernel works.
  - coldtea 4y ago
    The subthread though is about whether "any dev who can write Rust today is also a good C dev, ain't it?", not about kernel drivers...
dhruvdh 4y ago
There is a difference between not understanding and not wanting to write C.
- tbalsam 4y ago
  I'd be curious how C (and C++ for that matter) stacks up on some arbitrary "freshness" metric that measures some kind of statistic/statistics that indicate the average/median time it takes for the population of engineers to reach some particular level of "done"ness with a language. I have no idea how you would measure it, but I'm assuming that C, VBScript, Perl, sed, AWK, bash, and Haskell (please don't hurt me I'm thinking about the code maintenance, time draining nightmare that is a real-world use case of mega-scaled purely functional codebases as opposed to a mixed dynamic with a purely functional core). Curious what other languages would top the list. I'm going to assume also that some low-barrier entry scripting languages that are well designed, similar to Python, and languages that save the hypothetical, proverbial broken backs of their ancestors, like Rust, to be near the bottom of the list. I'm curious what that bottom part of the list would look like too, oddly enough. :D :))))
  - pitched 4y ago
    I would also really love to read a statistics-based approach to all of modern software engineering. Like, does SOLID actually increase bugs? Is Agile more likely to slow things down? Etc. This is the closest I’ve ever found: http://www.knosof.co.uk/ESEUR/ http://www.knosof.co.uk/ESEUR/
    - hedora 4y ago
      It strongly depends on the type of software being developed. As the abstract of that book suggests (when referring to ego and bluster), 100% of the agile proponents I have encountered are incompetent. (This especially includes organizations that claim they are "agile").
  - halpmeh 4y ago
    C is an amazing language. If you want to integrate into another language via FFI you basically have 0 other options. That being said, it’s too easy to do something wrong in C. The desire to use Rust isn’t because C is stale, rather it’s too hard to write C correctly.
    - Ar-Curunir 4y ago
      My desire to write Rust is for both reasons. C tooling is awful, the language offers insufficient abstraction capabilities, and, finally, is unsafe.
    - hedora 4y ago
      Rust and C++ both have C FFI boundaries that the compiler can inline across. What more do you want?
      - halpmeh 4y ago
        Well for one, I don’t want to add another language to my tool chain. Many languages can compile C directly. For instance in Swift or Go you can add C source files directly to your project and have them compile as part of your Swift or Go build. You can’t do that with Rust or C++. C is the lingua franca of the software development world.
rowanG077 4y ago
That's a pretty naive statement. No kernel dev knows what the rest of it is doing. Because the rest is a tens of millions of lines code base.
yazaddaruvala 4y ago
I understand C just fine, hacked on kernels before, could easily write “safe C”. 1. I just don’t enjoy C. At this point after writing so much code “for profit” it’s no longer a hobby in itself. If I’m writing code “for purpose” I need to enjoy it! 2. While I trust myself just enough to write some C, I don’t trust everyone else to retain a strong foundation for whatever I’m building on top. 3. C has carried the Linux kernel for its first 40 years. Having used Rust it’s clear the future (while maybe not Rust) is definitely not C. I want to make a contribution that will endure the next 40 years of Linux.

I would not want someone writing kernel code who can't understand what the rest of it is doing.

by rjsw 4y ago

I would not want someone writing kernel code who can't understand what the rest of it is doing.

Who said those people will be writing kernel code? Rust for the Linux kernel is like 0.000001% of real life Rust use (which is not that big to begin with). And it wouldn't be used the main kernel for the most part anyways, mostly (if not exclusively) kernel drivers.

rjsw 4y ago
This thread is about a kernel DRM driver written in Rust, writing any DRM driver requires a lot of knowledge about how the rest of the DRM subsystem and the kernel works.
- coldtea 4y ago
  The subthread though is about whether "any dev who can write Rust today is also a good C dev, ain't it?", not about kernel drivers...

dhruvdh 4y ago

There is a difference between not understanding and not wanting to write C.

tbalsam 4y ago
I'd be curious how C (and C++ for that matter) stacks up on some arbitrary "freshness" metric that measures some kind of statistic/statistics that indicate the average/median time it takes for the population of engineers to reach some particular level of "done"ness with a language. I have no idea how you would measure it, but I'm assuming that C, VBScript, Perl, sed, AWK, bash, and Haskell (please don't hurt me I'm thinking about the code maintenance, time draining nightmare that is a real-world use case of mega-scaled purely functional codebases as opposed to a mixed dynamic with a purely functional core). Curious what other languages would top the list. I'm going to assume also that some low-barrier entry scripting languages that are well designed, similar to Python, and languages that save the hypothetical, proverbial broken backs of their ancestors, like Rust, to be near the bottom of the list. I'm curious what that bottom part of the list would look like too, oddly enough. :D :))))
- pitched 4y ago
  I would also really love to read a statistics-based approach to all of modern software engineering. Like, does SOLID actually increase bugs? Is Agile more likely to slow things down? Etc. This is the closest I’ve ever found: http://www.knosof.co.uk/ESEUR/ http://www.knosof.co.uk/ESEUR/
  - hedora 4y ago
    It strongly depends on the type of software being developed. As the abstract of that book suggests (when referring to ego and bluster), 100% of the agile proponents I have encountered are incompetent. (This especially includes organizations that claim they are "agile").
- halpmeh 4y ago
  C is an amazing language. If you want to integrate into another language via FFI you basically have 0 other options. That being said, it’s too easy to do something wrong in C. The desire to use Rust isn’t because C is stale, rather it’s too hard to write C correctly.
  - Ar-Curunir 4y ago
    My desire to write Rust is for both reasons. C tooling is awful, the language offers insufficient abstraction capabilities, and, finally, is unsafe.
  - hedora 4y ago
    Rust and C++ both have C FFI boundaries that the compiler can inline across. What more do you want?
    - halpmeh 4y ago
      Well for one, I don’t want to add another language to my tool chain. Many languages can compile C directly. For instance in Swift or Go you can add C source files directly to your project and have them compile as part of your Swift or Go build. You can’t do that with Rust or C++. C is the lingua franca of the software development world.

rowanG077 4y ago

That's a pretty naive statement. No kernel dev knows what the rest of it is doing. Because the rest is a tens of millions of lines code base.

yazaddaruvala 4y ago

I understand C just fine, hacked on kernels before, could easily write “safe C”. 1. I just don’t enjoy C. At this point after writing so much code “for profit” it’s no longer a hobby in itself. If I’m writing code “for purpose” I need to enjoy it! 2. While I trust myself just enough to write some C, I don’t trust everyone else to retain a strong foundation for whatever I’m building on top. 3. C has carried the Linux kernel for its first 40 years. Having used Rust it’s clear the future (while maybe not Rust) is definitely not C. I want to make a contribution that will endure the next 40 years of Linux.