4 ms·

"What does this mean?" In general, mixing languages has serious long-term consequences. Unless you have done refactoring of large legacy systems... you probabl

"What does this mean?" In general, mixing languages has serious long-term consequences. Unless you have done refactoring of large legacy systems... you probably wouldn't understand fully. Perhaps ask why folks didn't create an isolated kernel branch for such a massive refactoring? "Rust doesn't support all the architectures that gcc does" Assuming a bootstrap compiler can even bring up Rust or the cargo monstrosity. People will just switch to other options, and maybe someone will get around to a Rusty Linux Fork if the working system needs entertaining drama. Best of luck =3

steveklabnik 2y ago
The kernel doesn’t use Cargo, by the way.
- Joel_Mckay 2y ago
  Indeed, its actually worse because "x.py" has a lot more dependencies. lol =3
  - steveklabnik 2y ago
    The kernel doesn’t use or interact with x.py either. The Rust code uses build to drive rustc, just like the rest of the kernel.
    - Joel_Mckay 2y ago
      I think you are operating under the assumption a fully compatible cross-compiler environment is already available in both languages. =3
      - steveklabnik 2y ago
        Drivers are hardware specific, and so it's not a problem that Rust has support for a subset of the platforms that the kernel does. If you want to write a driver for a platform Rust doesn't support, just write it in C.
        Joel_Mckay 2y ago
        "If you want to write a driver for a platform Rust doesn't support, just write it in C." ¯\_(ツ)_/¯ Or a separate branch for Rust in the first place. We are falling into the circular reasoning logic loop. lol =3
        Muromec 2y ago
        Drivers are usually hardware specific but are not always platform specific. For example all the usb device drivers (but not host drivers) from x86 work just fine on arm and risc. And kernel isn’t just device drivers, but also stuff like network — higher level abstractions are decoupled from platform quite good. I don’t think there is practical intersection of platforms not supporting rust and running USB host, but by the time rust will creep into something line network subsystem code you will either not have network (which was working before) or you make yourself a rust compiler. This can mean dropping platform support. Maybe those are dead platforms, but somebody will make the argument that adding rust made things objectively worse.
        steveklabnik 2y ago
        Sure. The point is, this is for new code where you know Rust supports the platform. It “creeping in” to something Rust can’t support won’t happen, because then the rust-less build will break. You are right that there are other policies that could work in a different way, but these policies were chosen specifically so that Rust doesn’t make the kernel sacrifice old platforms.
        Joel_Mckay 2y ago
        'It “creeping in” to something Rust can’t support won’t happen' The exact same argument could be made for future architectural changes, as OpenBSD/FreeBSD/NetBSD build requirements will now beat Polyglot Linux in every metric of porting complexity moving forwards. We can't have it both ways... Best regards =3
tremon 2y ago
Unless you have done refactoring of large legacy systems... you probably wouldn't understand fully. The reason I don't understand fully is because you don't explain yourself. I'm not convinved it has anything to do with my work experience.
- Joel_Mckay 2y ago
  "I'm not convinved it has anything to do with my work experience." I can see how that could be challenging, but some lessons are universal. This talk touches on the problem at an organizational level: https://www.youtube.com/watch?v=GWgRw5jiYy0 https://www.youtube.com/watch?v=GWgRw5jiYy0 Best I can do for you right now. Good luck =3
  - bdhcuidbebe 2y ago
    Just stop with the sarcasm, it doesnt belong here.
    - Joel_Mckay 2y ago
      The talk covers how polyglot projects tend to fail. Most folks can disagree on things, and remain respectful. Have a glorious day =3
      - SR2Z 2y ago
        Except... Most companies offer products built in multiple languages. Google notoriously has a multilingual monorepo and a uniform build system. Every company of non-trivial size uses multiple languages. Even Asahi Linux does! Polyglot projects are harder, but definitely not as hard as OS development in C.
        Joel_Mckay 2y ago
        Not sure employee attrition rates and canceled project metrics are a positive aspect of Google. https://en.wikipedia.org/wiki/List_of_Google_products#Discontinued_products_and_services https://en.wikipedia.org/wiki/List_of_Google_products#Discon... "definitely not as hard as OS development in C" Depends what you are doing, as complexity is often a sign of poor communication. https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law The talk pokes fun at the excuses folks make when kludging something they intended to replace later. =3

steveklabnik 2y ago

The kernel doesn’t use Cargo, by the way.

Joel_Mckay 2y ago
Indeed, its actually worse because "x.py" has a lot more dependencies. lol =3
- steveklabnik 2y ago
  The kernel doesn’t use or interact with x.py either. The Rust code uses build to drive rustc, just like the rest of the kernel.
  - Joel_Mckay 2y ago
    I think you are operating under the assumption a fully compatible cross-compiler environment is already available in both languages. =3
    - steveklabnik 2y ago
      Drivers are hardware specific, and so it's not a problem that Rust has support for a subset of the platforms that the kernel does. If you want to write a driver for a platform Rust doesn't support, just write it in C.
      - Joel_Mckay 2y ago
        "If you want to write a driver for a platform Rust doesn't support, just write it in C." ¯\_(ツ)_/¯ Or a separate branch for Rust in the first place. We are falling into the circular reasoning logic loop. lol =3
      - Muromec 2y ago
        Drivers are usually hardware specific but are not always platform specific. For example all the usb device drivers (but not host drivers) from x86 work just fine on arm and risc. And kernel isn’t just device drivers, but also stuff like network — higher level abstractions are decoupled from platform quite good. I don’t think there is practical intersection of platforms not supporting rust and running USB host, but by the time rust will creep into something line network subsystem code you will either not have network (which was working before) or you make yourself a rust compiler. This can mean dropping platform support. Maybe those are dead platforms, but somebody will make the argument that adding rust made things objectively worse.
        steveklabnik 2y ago
        Sure. The point is, this is for new code where you know Rust supports the platform. It “creeping in” to something Rust can’t support won’t happen, because then the rust-less build will break. You are right that there are other policies that could work in a different way, but these policies were chosen specifically so that Rust doesn’t make the kernel sacrifice old platforms.
        Joel_Mckay 2y ago
        'It “creeping in” to something Rust can’t support won’t happen' The exact same argument could be made for future architectural changes, as OpenBSD/FreeBSD/NetBSD build requirements will now beat Polyglot Linux in every metric of porting complexity moving forwards. We can't have it both ways... Best regards =3

tremon 2y ago

Unless you have done refactoring of large legacy systems... you probably wouldn't understand fully. The reason I don't understand fully is because you don't explain yourself. I'm not convinved it has anything to do with my work experience.

Joel_Mckay 2y ago
"I'm not convinved it has anything to do with my work experience." I can see how that could be challenging, but some lessons are universal. This talk touches on the problem at an organizational level: https://www.youtube.com/watch?v=GWgRw5jiYy0 https://www.youtube.com/watch?v=GWgRw5jiYy0 Best I can do for you right now. Good luck =3
- bdhcuidbebe 2y ago
  Just stop with the sarcasm, it doesnt belong here.
  - Joel_Mckay 2y ago
    The talk covers how polyglot projects tend to fail. Most folks can disagree on things, and remain respectful. Have a glorious day =3
    - SR2Z 2y ago
      Except... Most companies offer products built in multiple languages. Google notoriously has a multilingual monorepo and a uniform build system. Every company of non-trivial size uses multiple languages. Even Asahi Linux does! Polyglot projects are harder, but definitely not as hard as OS development in C.
      - Joel_Mckay 2y ago
        Not sure employee attrition rates and canceled project metrics are a positive aspect of Google. https://en.wikipedia.org/wiki/List_of_Google_products#Discontinued_products_and_services https://en.wikipedia.org/wiki/List_of_Google_products#Discon... "definitely not as hard as OS development in C" Depends what you are doing, as complexity is often a sign of poor communication. https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law The talk pokes fun at the excuses folks make when kludging something they intended to replace later. =3