7 ms·

> Introducing Rust is impossible for some platforms and hard for others. Please could someone elaborate on this.

ahdanggit 1y ago
Rust doesn't support as many CPU architectures as C does (SH4 for example, though there's likely many more better examples.) This might make a much more interesting case for GOT than before https://www.gameoftrees.org/ https://www.gameoftrees.org/
- 1oooqooq 1y ago
  got is a waste of time, imo. they could just port the multiprocess pledge stuff to git (and benefit linux too with namespaces) then all the userfacing changes (i.e. work on git bare instrad of wc) I've been doing for the last decade with a couple lines on my gitconfig file.
  - ahdanggit 1y ago
    Rust doesn't run on all of their platforms so this is a good example of where git may not be viable for OpenBSD long-term (if they were to switch from CVS one day, which is a big IF)
DarkNova6 1y ago
My understanding: As Rust is built on LLVM and not GCC, it is also limited to operating systems supporting LLVM. GCC simply supports more platforms.
- JoshTriplett 1y ago
  Rust has a GCC backend as well, rustc_codegen_gcc. However, the NonStop platform just has a proprietary C compiler.
  - okanat 1y ago
    MSVC is also proprietary. However LLVM is supported by Microsoft. The developer of Nonstop is apparently not doing that.
arccy 1y ago
because the rust compiler just doesn't support some platforms (os / architecture combination)? RESF members tend to say it the other way around as in the platform doesn't support rust, but the reality is that it's the compiler that needs to support a platform, not the other way around.
- JoshTriplett 1y ago
  Rust can't support a platform when that platform's vendors just provide a proprietary C compiler and nothing else (no LLVM, no GCC). Perhaps someone could reverse-engineer it, but ultimately a platform with zero support from any FOSS toolchain is unlikely to get Rust support anytime soon.
  - jen20 1y ago
    Furthermore, how could it without the donation of hardware, licenses and so forth?! This is a problem entirely of the proprietary platforms making, and it should be their customers problem for having made a poor decision.
    - kmeisthax 1y ago
      HPE's customers are big-pocketed enough that they absolutely could manage a Rust port themselves, or pay HPE however much money they need to get them to do it if they're going to play games with ABI documentation. NonStop isn't some kind of weird hobbyist or retrocomputing platform. Actually, I'm surprised HPE doesn't already ship a Rust fork, given how NonStop is supposed to be a "reliable" OS...
  - kazinator 1y ago
    Reverse that: "C can't support a platform when that platform's vendors just provide a proprietary Rust compiler and nothing else".
    - Yoric 1y ago
      Seems to me that that is equally true and doesn't remove any validity from the argument.
whalee 1y ago
See this page [1], particularly the 'Tier 3' platforms. [1] https://doc.rust-lang.org/beta/rustc/platform-support.html https://doc.rust-lang.org/beta/rustc/platform-support.html
- Alifatisk 1y ago
  More precise link https://doc.rust-lang.org/beta/rustc/platform-support.html#tier-3 https://doc.rust-lang.org/beta/rustc/platform-support.html#t...
- bbor 1y ago
  Thanks for the specifics, really fascinating list! I'm sure I'm being a bit flippant, but it's pretty funny that a list including the Playstation 1, N64, and Apple Watches is in the same conversation as systems that need to compile git from source. Anyone know of anything on that list with more than a thousand SWE-coded users? Presumably there's at least one or two for those in the know?
  - whalee 1y ago
    I don't think the concern is whether a user can compile git from source on said platform, but rather whether the rust standard lib is well supported on said platform, which is required for cross compiling.
  - loeg 1y ago
    In practice, the only systems any significant number of people care about running Git on are arm64 and x86-64, and those are very well supported.
  - 3036e4 1y ago
    What I like about seeing a project support a long list of totally irrelevant old obscure platforms (like Free Pascal does, and probably GCC) is that it gives some hope that they will support some future obscure platform that I may care about. It shows a sign of good engineering culture. If a project supports only 64-bit arm+x86 on the three currently most popular operating systems that is a red flag for future compatibility risks.
jmillikin 1y ago
There's at least one proprietary platform that supports Git built by via a vendor-provided C compiler, but for which no public documentation exists and therefore no LLVM support is possible. Ctrl+F for "NonStop" in https://lwn.net/Articles/998115/ https://lwn.net/Articles/998115/
- MangoToupe 1y ago
  How is this git's concern?
  - kazinator 1y ago
    Git's main concern should, of course, be getting Rust in, in some shape or form.
  - StopDisinfo910 1y ago
    They enjoy being portable and like things to stay that way so when they introduce a new toolchain dependency which will make it harder for some people to compile git, they point it out in their change log?
    - MangoToupe 1y ago
      I don't think "NonStop" is a good gauge of portability. But, I wasn't arguing against noting changes in a changelog, I'm arguing against putting portability to abstruse platforms before quality.
      - StopDisinfo910 1y ago
        I don’t think staying portable means you have to do concession on quality. That merely limit your ability to introduce less portable dependancies. But even then Git doesn’t mind losing some plateformes when they want to move forward on something.
- antihero 1y ago
  Shouldn't these platforms work on getting Rust to support it rather than have our tools limited by what they can consume? https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs
doctorpangloss 1y ago
You’re chasing after the meaning of “impossible.” Easy. There’s two categories of developers: > I like programming > I program to make money If you belong to the second category - I’m going to be super charitable, it sounds like I’m not going to be charitable and I am, so keep reading - such as by being paid by a giant bank to make applications on Nonstop, there might be some policy that’s like “You have to vet all open source code that runs on the computer.” So in order to have Rust, on Nonstop, to build git, which this guy likes, he’d need to port llvm, which isn’t impossible. What’s impossible is to get llvm code reviewed by legal, or whatever, which they’re not going to do, they’re going to say “No. No llvm. HP who makes Nonstop can do it, and it can be their legal problem.” I’m not saying it’s impossible. The other guy is saying it’s impossible, and I’m trying to show how, in a Rube Goldberg way, it looks impossible to him. You and I like programming, and I’m sure we’re both gainfully employed, though probably not making as much money at guy, but he doesn’t like programming. You are allowed to mock someone’s sincerity if they’re part of a system that’s sort of nakedly about making lots of money. But if you just like programming, you’d never work for a bank, it’s really fucking boring, so basically nobody who likes programming would ever say porting Rust or whatever is impossible. Do you see? It’s tough because, the Jane Street people and the Two Sigma people, they’re literally kids, they’re nice people, and they haven’t been there for very long, they still like programming! They feel like they need to mook for the bank, when they could just say that living in New York and having cocktails every night is fun and sincere. So this forum has the same problem as the mailing list, where it sounds like it’s about one thing - being able to use fucking hashmaps in git - and it’s really about another - bankers. Everywhere they turn, the bankers run into people who make their lifestyle possible, whether it’s the git developers who volunteer their time or the parents of the baristas at the bars they’re going to paying the baristas’ rent - and the bankers keep hating on these people. And then they go and say, well everyone is the problem but me. They don’t get it yet.
- eklavya 1y ago
  What are you on about?
daurentius523 1y ago
To put in simply. Linux systems: Any library is system library because otherwise there will be no real OS libraries or API. Rust: No ABI. = No (real) shared libraries. Debian: https://www.debian.org/releases/trixie/release-notes/issues.html#go-and-rust-based-packages https://www.debian.org/releases/trixie/release-notes/issues.... Me who wrote long, long comment and then accidentally pushed close tab shortcut. !!@@! I would recommend building some packages containing rust, especially on older hardware - and then realize that because of static linking you will need to rebuild it very very often - and don't forget that you are building clean. Because it is expected that you will use required shared libraries to make life easier. I think that rust people should maybe sometimes just consider - that rust if pushed in such way will be more hated than C. Maybe you should not try to deflect criticism about stable ABI and shared libraries - linux OSes REQUIRE IT - nobody will change OS architecture because you want it. And maybe we should be more conservative architecturally in especially most critical pieces of software architecture.
- comex 1y ago
  Not especially relevant for Git which has never provided a shared library interface.
  - daurentius523 1y ago
    It gives rust hate from many people. And once someone hates language it sticks. Also add to that the rust zealots who behave like sometimes like political preachers. "We are future, you are backwards" - says every ideologue. But conveniently does not say "in direction I want". When rust started political fight instead of language one they should expect that every rust porting will become political quagmire. Also you are incorrect - because you are already making wrong assumption: > crates are not libraries "never provided a shared library interface" - it doesn't need to, it just need to USE library - distros will convert static one to shared one if that what is reasonable. Now we have to have C library connected by C headers to (in future) rust application. Sure this somehow works - at cost of memory safety. So someone WILL suggest using rust crate instead of C library, and the problem will inevitably pop up. You could only say it works correctly as platform stipulates if you did not use any rust crate, or used ones that only your app/lib uses, or trivial finished ones - and I do not see people use rust like that. Even then it is from most linux distributions perspective the distribution job to decide if it should be static or shared linked NOT app-developer. SSL is something that is prime example of would it best to be written in memory safe language, with safe headers, provided that language makes stable ABI connections, so we can update 0-day not waiting for app developer. Rust fails spectacularly at last point unless library uses C headers. But at least it seems that OpenSSL is dynamically loaded after start so they are not changing that too soon. When I decide to patch some library for my use case I may want to use such library in every instance in every program on the system. Rust crate makes this impossible - now I need to rebuild everything even if I could not reasonably touch ABI boundary in same C code. Ultimately I think many of linux rust critics see it correctly as company-first/app-centered/containerized/not developement-aware user language (i.e user who can patch software for their specific needs who actively want to inspect every dependency in ONE way), and they prefer the known pro-community/pro-distro/pro-user-developer C/C++ paradigm instead. (At least fact that many criticism start immediately when GPL project get BSD rust rewrite does point it to free-software/open-source i.e pro-community/pro-company schism) Many linux users especially developement-aware users just have enough of pip, cargo and every 'modern' stuff - they just want old good apt or pacman. Then you have people that think slow development and no revolutionary changes should be IT priority in modern times. Then you have people that do believe that any alternative should be better, easier and simpler than old stuff before it should be treated as even a alternative way. And then you have contrarians.

Rust doesn't support as many CPU architectures as C does (SH4 for example, though there's likely many more better examples.) This might make a much more interesting case for GOT than before https://www.gameoftrees.org/ https://www.gameoftrees.org/

1oooqooq 1y ago
got is a waste of time, imo. they could just port the multiprocess pledge stuff to git (and benefit linux too with namespaces) then all the userfacing changes (i.e. work on git bare instrad of wc) I've been doing for the last decade with a couple lines on my gitconfig file.
- ahdanggit 1y ago
  Rust doesn't run on all of their platforms so this is a good example of where git may not be viable for OpenBSD long-term (if they were to switch from CVS one day, which is a big IF)

DarkNova6 1y ago

My understanding: As Rust is built on LLVM and not GCC, it is also limited to operating systems supporting LLVM. GCC simply supports more platforms.

JoshTriplett 1y ago
Rust has a GCC backend as well, rustc_codegen_gcc. However, the NonStop platform just has a proprietary C compiler.
- okanat 1y ago
  MSVC is also proprietary. However LLVM is supported by Microsoft. The developer of Nonstop is apparently not doing that.

arccy 1y ago

because the rust compiler just doesn't support some platforms (os / architecture combination)? RESF members tend to say it the other way around as in the platform doesn't support rust, but the reality is that it's the compiler that needs to support a platform, not the other way around.

JoshTriplett 1y ago
Rust can't support a platform when that platform's vendors just provide a proprietary C compiler and nothing else (no LLVM, no GCC). Perhaps someone could reverse-engineer it, but ultimately a platform with zero support from any FOSS toolchain is unlikely to get Rust support anytime soon.
- jen20 1y ago
  Furthermore, how could it without the donation of hardware, licenses and so forth?! This is a problem entirely of the proprietary platforms making, and it should be their customers problem for having made a poor decision.
  - kmeisthax 1y ago
    HPE's customers are big-pocketed enough that they absolutely could manage a Rust port themselves, or pay HPE however much money they need to get them to do it if they're going to play games with ABI documentation. NonStop isn't some kind of weird hobbyist or retrocomputing platform. Actually, I'm surprised HPE doesn't already ship a Rust fork, given how NonStop is supposed to be a "reliable" OS...
- kazinator 1y ago
  Reverse that: "C can't support a platform when that platform's vendors just provide a proprietary Rust compiler and nothing else".
  - Yoric 1y ago
    Seems to me that that is equally true and doesn't remove any validity from the argument.

whalee 1y ago

See this page [1], particularly the 'Tier 3' platforms. [1] https://doc.rust-lang.org/beta/rustc/platform-support.html https://doc.rust-lang.org/beta/rustc/platform-support.html

Alifatisk 1y ago
More precise link https://doc.rust-lang.org/beta/rustc/platform-support.html#tier-3 https://doc.rust-lang.org/beta/rustc/platform-support.html#t...
bbor 1y ago
Thanks for the specifics, really fascinating list! I'm sure I'm being a bit flippant, but it's pretty funny that a list including the Playstation 1, N64, and Apple Watches is in the same conversation as systems that need to compile git from source. Anyone know of anything on that list with more than a thousand SWE-coded users? Presumably there's at least one or two for those in the know?
- whalee 1y ago
  I don't think the concern is whether a user can compile git from source on said platform, but rather whether the rust standard lib is well supported on said platform, which is required for cross compiling.
- loeg 1y ago
  In practice, the only systems any significant number of people care about running Git on are arm64 and x86-64, and those are very well supported.
- 3036e4 1y ago
  What I like about seeing a project support a long list of totally irrelevant old obscure platforms (like Free Pascal does, and probably GCC) is that it gives some hope that they will support some future obscure platform that I may care about. It shows a sign of good engineering culture. If a project supports only 64-bit arm+x86 on the three currently most popular operating systems that is a red flag for future compatibility risks.

jmillikin 1y ago

There's at least one proprietary platform that supports Git built by via a vendor-provided C compiler, but for which no public documentation exists and therefore no LLVM support is possible. Ctrl+F for "NonStop" in https://lwn.net/Articles/998115/ https://lwn.net/Articles/998115/

MangoToupe 1y ago
How is this git's concern?
- kazinator 1y ago
  Git's main concern should, of course, be getting Rust in, in some shape or form.
- StopDisinfo910 1y ago
  They enjoy being portable and like things to stay that way so when they introduce a new toolchain dependency which will make it harder for some people to compile git, they point it out in their change log?
  - MangoToupe 1y ago
    I don't think "NonStop" is a good gauge of portability. But, I wasn't arguing against noting changes in a changelog, I'm arguing against putting portability to abstruse platforms before quality.
    - StopDisinfo910 1y ago
      I don’t think staying portable means you have to do concession on quality. That merely limit your ability to introduce less portable dependancies. But even then Git doesn’t mind losing some plateformes when they want to move forward on something.
antihero 1y ago
Shouldn't these platforms work on getting Rust to support it rather than have our tools limited by what they can consume? https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs

doctorpangloss 1y ago

You’re chasing after the meaning of “impossible.” Easy. There’s two categories of developers: > I like programming > I program to make money If you belong to the second category - I’m going to be super charitable, it sounds like I’m not going to be charitable and I am, so keep reading - such as by being paid by a giant bank to make applications on Nonstop, there might be some policy that’s like “You have to vet all open source code that runs on the computer.” So in order to have Rust, on Nonstop, to build git, which this guy likes, he’d need to port llvm, which isn’t impossible. What’s impossible is to get llvm code reviewed by legal, or whatever, which they’re not going to do, they’re going to say “No. No llvm. HP who makes Nonstop can do it, and it can be their legal problem.” I’m not saying it’s impossible. The other guy is saying it’s impossible, and I’m trying to show how, in a Rube Goldberg way, it looks impossible to him. You and I like programming, and I’m sure we’re both gainfully employed, though probably not making as much money at guy, but he doesn’t like programming. You are allowed to mock someone’s sincerity if they’re part of a system that’s sort of nakedly about making lots of money. But if you just like programming, you’d never work for a bank, it’s really fucking boring, so basically nobody who likes programming would ever say porting Rust or whatever is impossible. Do you see? It’s tough because, the Jane Street people and the Two Sigma people, they’re literally kids, they’re nice people, and they haven’t been there for very long, they still like programming! They feel like they need to mook for the bank, when they could just say that living in New York and having cocktails every night is fun and sincere. So this forum has the same problem as the mailing list, where it sounds like it’s about one thing - being able to use fucking hashmaps in git - and it’s really about another - bankers. Everywhere they turn, the bankers run into people who make their lifestyle possible, whether it’s the git developers who volunteer their time or the parents of the baristas at the bars they’re going to paying the baristas’ rent - and the bankers keep hating on these people. And then they go and say, well everyone is the problem but me. They don’t get it yet.

eklavya 1y ago
What are you on about?

daurentius523 1y ago

To put in simply. Linux systems: Any library is system library because otherwise there will be no real OS libraries or API. Rust: No ABI. = No (real) shared libraries. Debian: https://www.debian.org/releases/trixie/release-notes/issues.html#go-and-rust-based-packages https://www.debian.org/releases/trixie/release-notes/issues.... Me who wrote long, long comment and then accidentally pushed close tab shortcut. !!@@! I would recommend building some packages containing rust, especially on older hardware - and then realize that because of static linking you will need to rebuild it very very often - and don't forget that you are building clean. Because it is expected that you will use required shared libraries to make life easier. I think that rust people should maybe sometimes just consider - that rust if pushed in such way will be more hated than C. Maybe you should not try to deflect criticism about stable ABI and shared libraries - linux OSes REQUIRE IT - nobody will change OS architecture because you want it. And maybe we should be more conservative architecturally in especially most critical pieces of software architecture.

comex 1y ago
Not especially relevant for Git which has never provided a shared library interface.
- daurentius523 1y ago
  It gives rust hate from many people. And once someone hates language it sticks. Also add to that the rust zealots who behave like sometimes like political preachers. "We are future, you are backwards" - says every ideologue. But conveniently does not say "in direction I want". When rust started political fight instead of language one they should expect that every rust porting will become political quagmire. Also you are incorrect - because you are already making wrong assumption: > crates are not libraries "never provided a shared library interface" - it doesn't need to, it just need to USE library - distros will convert static one to shared one if that what is reasonable. Now we have to have C library connected by C headers to (in future) rust application. Sure this somehow works - at cost of memory safety. So someone WILL suggest using rust crate instead of C library, and the problem will inevitably pop up. You could only say it works correctly as platform stipulates if you did not use any rust crate, or used ones that only your app/lib uses, or trivial finished ones - and I do not see people use rust like that. Even then it is from most linux distributions perspective the distribution job to decide if it should be static or shared linked NOT app-developer. SSL is something that is prime example of would it best to be written in memory safe language, with safe headers, provided that language makes stable ABI connections, so we can update 0-day not waiting for app developer. Rust fails spectacularly at last point unless library uses C headers. But at least it seems that OpenSSL is dynamically loaded after start so they are not changing that too soon. When I decide to patch some library for my use case I may want to use such library in every instance in every program on the system. Rust crate makes this impossible - now I need to rebuild everything even if I could not reasonably touch ABI boundary in same C code. Ultimately I think many of linux rust critics see it correctly as company-first/app-centered/containerized/not developement-aware user language (i.e user who can patch software for their specific needs who actively want to inspect every dependency in ONE way), and they prefer the known pro-community/pro-distro/pro-user-developer C/C++ paradigm instead. (At least fact that many criticism start immediately when GPL project get BSD rust rewrite does point it to free-software/open-source i.e pro-community/pro-company schism) Many linux users especially developement-aware users just have enough of pip, cargo and every 'modern' stuff - they just want old good apt or pacman. Then you have people that think slow development and no revolutionary changes should be IT priority in modern times. Then you have people that do believe that any alternative should be better, easier and simpler than old stuff before it should be treated as even a alternative way. And then you have contrarians.