4 ms·

Your charitable reading is too charitable. One of the benefits of using types to help guarantee properties of programs (e.g. invariants) is that types do not g

by mietek 2y ago

Your charitable reading is too charitable. One of the benefits of using types to help guarantee properties of programs (e.g. invariants) is that types do not get out of sync with the code, because they are part of the code, unlike documentation. The language implementation (e.g. the compiler) automatically checks that the types continue to match the rest of the code, in order to catch problems as early as possible.

diggan 2y ago
I'm not a kernel developer, and never done anything of the sorts either. But, I think the argument is that if they have two versions of something (the C version + the Rust bindings), the logic/behavior/"semantics" of the C version would need to be encoded into the Rust types, and if a C-only developer changes the C version only, how are they supposed to proceed with updating the Rust bindings if they don't want to write Rust? At least that's my understanding from the outside, someone please do correct me if wrong.
- bcrosby95 2y ago
  That was a large part of the disagreement. Rust developers were saying it would be their job to do this. But then someone said Linus rejected something because it broke Rust. GKH backed the Rust developers and said that was an exception not a rule, but didn't know Linus' stance for sure. Then Linus chimes in because of one of Hector's replies, but at the time of my reading did not clarify what his actual stance is here.
  - ChocolateGod 2y ago
    > but at the time of my reading did not clarify what his actual stance is here. Whatever he says is guaranteed to piss off at least one side of the argument.
    - rekoil 2y ago
      Yeah it's not an easy discussion for sure, but he has to say something. At the rate we're going here the existing kernel devs will alienate any capable new blood, and Linux will eventually become Google Linux(TM) as the old guard goes into retirement and the only possible way forward is through money.
      - procaryote 2y ago
        Doesn't that assume all "capable new blood" is enthusiastic about rust in the kernel? It seems like a pretty big assumption
        rekoil 2y ago
        You’re not wrong (in that I was insinuating something like that), but I’ll point out it’s an almost equally big assumption that we’re somehow going to find a trove of capable developers interested in devoting their careers to coding in ancient versions of C.
      - lukaslalinsky 2y ago
        Do you really think there are no young people wanting to work on an operating system written in C? I'm very skeptical that all young people interested in operating systems see Rust as the future. I personally feel it's the other way around, it's Google and companies like that who really want Rust in Linux, the young kernel devs are a minority.
        veidr 2y ago
        It's not that people think that there are no young people wanting to work in C, it's that the number of competent programmers who want to use C, or do use C, are both decreasing every year. That has been the trend for quite a while now. So there will presumably be fewer and fewer programmers, young or old, that want to work in C. C is one of the most entrenched and still-important languages in the world, so it probably has more staying power than Fortran, COBOL, etc. So the timeline is anybody's guess, but the trajectory is pretty clear. There are a lot of languages that people prefer to C which aren't well-suited to OS programming (golang, Java) but Rust is one that can do the same job as C, and is increasingly popular, and famously well-loved by its users. There's no guarantee that Rust will work out for Linux. Looks unlikely, to me, actually. But I think it's pretty clear that Linux will face a dwindling talent pool if the nebulous powers that actually control it collectively reject everything that is not C.
    - deleted 2y ago
      [deleted]
    - dralley 2y ago
      You still have to make the stance clear. Avoiding conflicts and dealing with them are two different things.
- ChocolateGod 2y ago
  > how are they supposed to proceed with updating the Rust bindings if they don't want to write Rust? If I've interpreted it correctly (and probably not, given the arguments), Linus won't accept merge requests if they break the Rust code, so the maintainer would need to reach out to the Rust for Linux (or someone else) to fix it if they didn't want to themselves. And some lead maintainers don't want to have to do that, so said no Rust in their subsystem.
- rekoil 2y ago
  Which is a moot point because the agreement right now is that Rust code is allowed to break, so the C developer in question can just ignore Rust, and a Rust person will take care of it for them.
  - diggan 2y ago
    > Which is a moot point because the agreement right now is that Rust code is allowed to break, so the C developer in question can just ignore Rust So then the argument that even semantics encoded in the Rust types, can be out of the date compared to the actual code, is actually a real thing? I read that somewhere else here in the comments, but didn't understand how the types could ever be out-of-date, but this would explain that argument.
    - rekoil 2y ago
      As I understand it everything Rust is seen as "optional", so a CONFIG_RUST=n build that succeeds means a-OK, then some Rust person will do a CONFIG_RUST=y build, see it's broken, fix it, and submit a patch. I may be wrong, but that's how I understood it, but who knows how Linus will handle any given situation. ¯\_(ツ)_/¯
    - rowanG077 2y ago
      That's exactly what would happen "types get out of date". I'm not sure what you are familiar with. But imagine in python a new version of a library is released that now has an extra required argument on a function.
  - rc00 2y ago
    As of today, the burden is uncertain and the Rust crowd has not been fixing things quickly enough since they are manual fixes: https://lore.kernel.org/rust-for-linux/20250131135421.GO5556@nvidia.com/ https://lore.kernel.org/rust-for-linux/20250131135421.GO5556... > Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not. > Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders". > It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build. For clarity, tree-wide fixes for C in the kernel are automated via Coccinelle. Coccinelle for Rust is constantly unstable and broken which is why manual fixes are required. Does this help to explain the burden that C developers are facing because of Rust and how it is in addition to their existing workloads?
Certhas 2y ago
Yes, but generic code complicates the picture. The things I saw were like: The documentation says you need a number but actually all you need is for the + operator to be defined. So if your interface only accepts numbers it is unnecessarily restrictive. Conversely some codepath might use * but that is not in the interface, so your generic code works for numbers but fails for other types that should work.
- s1mplicissimus 2y ago
  > Yes, but generic code complicates the picture. The things I saw were like: The documentation says you need a number but actually all you need is for the + operator to be defined. So if your interface only accepts numbers it is unnecessarily restrictive. if you really need a number, why not use a type specifically aligned to that (something like f32|f64|i32|i64 etc...) instead of relying on + operator definition? > Conversely some codepath might use * but that is not in the interface, so your generic code works for numbers but fails for other types that should work. do we agree that if it's not in the interface you are not supposed to use it? conversely if you want to use it, the interface has to be extended?
  - Certhas 2y ago
    Yes, the second case is a bug in the interface. For the first case you have it the wrong way around. My generic code would work on things that are not numbers but I prevent you from calling it because I didn't anticipate that there would be things you can add that are not numbers. (Better example: require an array when you really only need an iterable).

by mietek 2y ago

diggan 2y ago

I'm not a kernel developer, and never done anything of the sorts either. But, I think the argument is that if they have two versions of something (the C version + the Rust bindings), the logic/behavior/"semantics" of the C version would need to be encoded into the Rust types, and if a C-only developer changes the C version only, how are they supposed to proceed with updating the Rust bindings if they don't want to write Rust? At least that's my understanding from the outside, someone please do correct me if wrong.

bcrosby95 2y ago
That was a large part of the disagreement. Rust developers were saying it would be their job to do this. But then someone said Linus rejected something because it broke Rust. GKH backed the Rust developers and said that was an exception not a rule, but didn't know Linus' stance for sure. Then Linus chimes in because of one of Hector's replies, but at the time of my reading did not clarify what his actual stance is here.
- ChocolateGod 2y ago
  > but at the time of my reading did not clarify what his actual stance is here. Whatever he says is guaranteed to piss off at least one side of the argument.
  - rekoil 2y ago
    Yeah it's not an easy discussion for sure, but he has to say something. At the rate we're going here the existing kernel devs will alienate any capable new blood, and Linux will eventually become Google Linux(TM) as the old guard goes into retirement and the only possible way forward is through money.
    - procaryote 2y ago
      Doesn't that assume all "capable new blood" is enthusiastic about rust in the kernel? It seems like a pretty big assumption
      - rekoil 2y ago
        You’re not wrong (in that I was insinuating something like that), but I’ll point out it’s an almost equally big assumption that we’re somehow going to find a trove of capable developers interested in devoting their careers to coding in ancient versions of C.
    - lukaslalinsky 2y ago
      Do you really think there are no young people wanting to work on an operating system written in C? I'm very skeptical that all young people interested in operating systems see Rust as the future. I personally feel it's the other way around, it's Google and companies like that who really want Rust in Linux, the young kernel devs are a minority.
      - veidr 2y ago
        It's not that people think that there are no young people wanting to work in C, it's that the number of competent programmers who want to use C, or do use C, are both decreasing every year. That has been the trend for quite a while now. So there will presumably be fewer and fewer programmers, young or old, that want to work in C. C is one of the most entrenched and still-important languages in the world, so it probably has more staying power than Fortran, COBOL, etc. So the timeline is anybody's guess, but the trajectory is pretty clear. There are a lot of languages that people prefer to C which aren't well-suited to OS programming (golang, Java) but Rust is one that can do the same job as C, and is increasingly popular, and famously well-loved by its users. There's no guarantee that Rust will work out for Linux. Looks unlikely, to me, actually. But I think it's pretty clear that Linux will face a dwindling talent pool if the nebulous powers that actually control it collectively reject everything that is not C.
  - deleted 2y ago
    [deleted]
  - dralley 2y ago
    You still have to make the stance clear. Avoiding conflicts and dealing with them are two different things.
ChocolateGod 2y ago
> how are they supposed to proceed with updating the Rust bindings if they don't want to write Rust? If I've interpreted it correctly (and probably not, given the arguments), Linus won't accept merge requests if they break the Rust code, so the maintainer would need to reach out to the Rust for Linux (or someone else) to fix it if they didn't want to themselves. And some lead maintainers don't want to have to do that, so said no Rust in their subsystem.
rekoil 2y ago
Which is a moot point because the agreement right now is that Rust code is allowed to break, so the C developer in question can just ignore Rust, and a Rust person will take care of it for them.
- diggan 2y ago
  > Which is a moot point because the agreement right now is that Rust code is allowed to break, so the C developer in question can just ignore Rust So then the argument that even semantics encoded in the Rust types, can be out of the date compared to the actual code, is actually a real thing? I read that somewhere else here in the comments, but didn't understand how the types could ever be out-of-date, but this would explain that argument.
  - rekoil 2y ago
    As I understand it everything Rust is seen as "optional", so a CONFIG_RUST=n build that succeeds means a-OK, then some Rust person will do a CONFIG_RUST=y build, see it's broken, fix it, and submit a patch. I may be wrong, but that's how I understood it, but who knows how Linus will handle any given situation. ¯\_(ツ)_/¯
  - rowanG077 2y ago
    That's exactly what would happen "types get out of date". I'm not sure what you are familiar with. But imagine in python a new version of a library is released that now has an extra required argument on a function.
- rc00 2y ago
  As of today, the burden is uncertain and the Rust crowd has not been fixing things quickly enough since they are manual fixes: https://lore.kernel.org/rust-for-linux/20250131135421.GO5556@nvidia.com/ https://lore.kernel.org/rust-for-linux/20250131135421.GO5556... > Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not. > Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders". > It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build. For clarity, tree-wide fixes for C in the kernel are automated via Coccinelle. Coccinelle for Rust is constantly unstable and broken which is why manual fixes are required. Does this help to explain the burden that C developers are facing because of Rust and how it is in addition to their existing workloads?

Certhas 2y ago

Yes, but generic code complicates the picture. The things I saw were like: The documentation says you need a number but actually all you need is for the + operator to be defined. So if your interface only accepts numbers it is unnecessarily restrictive. Conversely some codepath might use * but that is not in the interface, so your generic code works for numbers but fails for other types that should work.

s1mplicissimus 2y ago
> Yes, but generic code complicates the picture. The things I saw were like: The documentation says you need a number but actually all you need is for the + operator to be defined. So if your interface only accepts numbers it is unnecessarily restrictive. if you really need a number, why not use a type specifically aligned to that (something like f32|f64|i32|i64 etc...) instead of relying on + operator definition? > Conversely some codepath might use * but that is not in the interface, so your generic code works for numbers but fails for other types that should work. do we agree that if it's not in the interface you are not supposed to use it? conversely if you want to use it, the interface has to be extended?
- Certhas 2y ago
  Yes, the second case is a bug in the interface. For the first case you have it the wrong way around. My generic code would work on things that are not numbers but I prevent you from calling it because I didn't anticipate that there would be things you can add that are not numbers. (Better example: require an array when you really only need an iterable).