5 ms·

Why is there such a push to use this new language that's so inaccessible to much of the world? Not everyone has a multi-gigahertz, multi-core, multi-gigabyte co

Why is there such a push to use this new language that's so inaccessible to much of the world? Not everyone has a multi-gigahertz, multi-core, multi-gigabyte computer to develop in Rust. It seems like unnecessary stratification for nebulous gain. Perhaps the Rust team should make their compiler work on reasonable resources, like 32 bit processors, before marching off to try to convert the world. Or perhaps we should have rust2c instead, so people can take all this Rust code that everyone is pushing and compile it on modest machines.

steveklabnik 7y ago
We distribute binaries of the compiler for a bunch of 32 bit targets. It will of course be slower on slower machines, but that’s just physics. mrustc is "rust to C", though it's not quite ready for the general case yet. It's primarily for translating the compiler, to ease bootstrapping.
twblalock 7y ago
> Perhaps the Rust team should make their compiler work on reasonable resources, like 32 bit processors, before marching off to try to convert the world. It's time to let 32-bit processors go and move on.
- deleted 7y ago
  [deleted]
- AceJohnny2 7y ago
  There are magnitudes more processors out there than desktop- or server-class.
  - tverbeure 7y ago
    How many of those processors are used to compile code? The complaint above is about that. Running compiled Rust code on a tiny embedded microcontroller is not a problem. https://medium.com/coinmonks/coding-the-stm32-blue-pill-with-rust-and-visual-studio-code-b21615d8a20 https://medium.com/coinmonks/coding-the-stm32-blue-pill-with...
zozbot234 7y ago
Even some large C++ projects are becoming hard or perhaps impossible to build using a 32-bit compiler. It's not something that only hits Rust.
vmchale 7y ago
> Why is there such a push to use this new language that's so inaccessible to much of the world? Eh?
- thedaemon 7y ago
  Not everyone is a rich American or European, many people live in what would be considered a poor country. They might have a core2duo if very lucky. The entitlement on this website is getting out of hand.
  - p1necone 7y ago
    Is there any data out there on this?
    - thedaemon 7y ago
      https://www.worldatlas.com/articles/the-poorest-countries-in-the-world.html https://www.worldatlas.com/articles/the-poorest-countries-in...
  - vmchale 7y ago
    But why is Rust a problem there? Surely it is not fundamentally incompatible with 32-bit architectures?
  - heavenlyblue 7y ago
    You will get it in a few years when you buy it cheap used from Americans and Europeans?
smolder 7y ago
The compiler performance may be a perfectly valid reason not to use Rust. Don't mistake the frequent Rust articles for the whole world moving to Rust. It's more like a few excited pioneers exploring its use cases and doing foundational work. Besides, if it helps other people build more stable, secure, or better performing software tools for you to use, isn't that good, even if you don't use it directly yourself?
tracker1 7y ago
First, rust provides safety checks you don't get in C. Second, the only way you'd improve compiler performance via C conversion would bypass these checks. Third, transpiling through C without these safety checks loses the point of rust in the first place. The fact is, that there are a great many bugs in the wild that never would have happened in idiomatic rust in the first place. Yes, there is additional overhead to compiling. By comparison, if you use static code analysis on your C/C++ code there is additional overhead, and even then a greater chance of security bugs slipping by compared to rust. In the end, used server hardware is relatively cheap in most of the world, which does pretty well with this type of code. There are a lot of people using mid-upper range x86 hardware and even to cross-platform compile to lower end arm64 support. At some point, it's less worth maintaining legacy hardware either for pragmatic and/or practical reasons. Rust was started well after x64 and other 64-bit hardware was in the wild, and 32-bit hardware was for the most part no longer being produced. Supporting such systems is work that practically speaking is less valuable to most people. As someone that really likes the old DOS based BBS software and related tech, and even supports Telnet BBSes today, I don't always like seeing this left behind to some extent. Last year, a large portion of the community blew up when 32bit was going to be dropped from Ubuntu, mainly because of the need required by wine and the gaming community. This isn't about supporting 10+ year old apps and programs in an emulated environment... this is about porting existing code in an automated enough way to improve stability and support-ability over time by leveraging a safer language.
AceJohnny2 7y ago
> Perhaps the Rust team should make their compiler work on reasonable resources, like 32 bit processors Rust compiles for and runs on STM32, a 32-bit microcontroller: https://docs.rust-embedded.org/discovery/ https://docs.rust-embedded.org/discovery/ And here's an index of supported embedded hardware: https://github.com/rust-embedded/awesome-embedded-rust#driver-crates https://github.com/rust-embedded/awesome-embedded-rust#drive...
- monocasa 7y ago
  He's saying for running the compiler, not for the compilation target I think.
  - heavenlyblue 7y ago
    Then you can compile the compiler for that platform, no? That being said you would need to implement the basics of OS routines, but it should not be too hard
    - monocasa 7y ago
      Not if the compiler can't fit in memory. And rustc has problems fitting non trivial projects in 2GB of RAM.
- andai 7y ago
  > Perhaps the Rust team should make their compiler work on reasonable resources, like 32 bit processors >Rust compiles for and runs on STM32, a 32-bit microcontroller Cool, but it can't run the compiler, right? I think that's what GP meant.
  - sedatk 7y ago
    I wouldn't call 32-bit processors reasonable anymore. Maybe a decade ago, yes. 64-bit is the norm now. It doesn't make sense to demand 32-bit support.
elihu 7y ago
Poor computer security poses an existential threat to modern civilization. Slow-ish compile times do not.
- hinkley 7y ago
  I'd heard that the Rust compiler can't compile itself on a 32 bit machine with maxed out RAM. I know there have been some changes to shrink memory usage for a bunch of data types in Rust but it's not clear if that has changed this limitation. I'm trying to learn Rust now, and one of my eventual goals is to look into heap analysis of the compiler, because I agree this is some bullshit. I want to run stuff on ARM eventually and cross compilation and transfer don't sound like my idea of a good time.
  - steveklabnik 7y ago
    This is not entirely a rustc issue; LLVM is a huge part of this as well. Sometimes, some steps need more than four gigs of RAM. loc says that rustc has 1.4 million lines of Rust, and LLVM has 5 million of C++. It's just a huge project. In the past, people have reported these things, and we've tried to fix or help where possible; see the discussion on https://github.com/rust-lang/rust/issues/60294 https://github.com/rust-lang/rust/issues/60294 for example.
  - estebank 7y ago
    You would only need cross compilation of your project is as big as rustc, but if it were you would likely want the fastest available machine at your disposal and a lot of effort is poured into making cross compilation as painless as possible. Making rustc compilable in a 32bits host might be a good idea, but it is far from a priority. If that is a deal breaker, as it is for OpenBSD for example, Rust is certainly a language that you should look at in the short term.
antpls 7y ago
> Not everyone has a multi-gigahertz, multi-core, multi-gigabyte computer to develop in Rust. Even low-end Android phones have multi-gigahertz, multi-core, multi-gigabyte memory, so actually, many people have that in their pockets
p1necone 7y ago
> "multi-gigahertz, multi-core, multi-gigabyte" Unless you're talking about people holding on to hardware from 20+ years ago then yes - basically everyone with a computer, or a mobile phone has something that fits that classification. People complain about Rust having long compile times, but I doubt it would be unusably bad even on something like a core 2 duo.
damnyou 7y ago
Rust trades off compile time performance for runtime correctness and performance. Far more people run code than compile it.
imtringued 7y ago
I'm not working with Rust but I just tried a quick benchmark by compiling a random project. git clone https://github.com/hyperium/hyper https://github.com/hyperium/hyper Full Build: time cargo build (1 min 42 seconds without download) (349K LOC total [0]) Recompile: time cargo build (2 seconds) (around 18k LOC) I don't see the problem. The full build also includes all the 53 dependencies. So we are talking about a compilation speed of about 3.5k lines/s on a dual core 11" laptop from 2017 with turbo boost disabled. I've personally worked on C++ projects where changing a single header can cause 5 minutes of compilation on an incremental build. Any slowdowns you have experienced may have been caused by a specific library or project. [0] according to cloc ~/.cargo/registry/src/github.com-1ecc6299db9ec823/

steveklabnik 7y ago

We distribute binaries of the compiler for a bunch of 32 bit targets. It will of course be slower on slower machines, but that’s just physics. mrustc is "rust to C", though it's not quite ready for the general case yet. It's primarily for translating the compiler, to ease bootstrapping.

twblalock 7y ago

> Perhaps the Rust team should make their compiler work on reasonable resources, like 32 bit processors, before marching off to try to convert the world. It's time to let 32-bit processors go and move on.

deleted 7y ago
[deleted]
AceJohnny2 7y ago
There are magnitudes more processors out there than desktop- or server-class.
- tverbeure 7y ago
  How many of those processors are used to compile code? The complaint above is about that. Running compiled Rust code on a tiny embedded microcontroller is not a problem. https://medium.com/coinmonks/coding-the-stm32-blue-pill-with-rust-and-visual-studio-code-b21615d8a20 https://medium.com/coinmonks/coding-the-stm32-blue-pill-with...

zozbot234 7y ago

Even some large C++ projects are becoming hard or perhaps impossible to build using a 32-bit compiler. It's not something that only hits Rust.

vmchale 7y ago

> Why is there such a push to use this new language that's so inaccessible to much of the world? Eh?

thedaemon 7y ago
Not everyone is a rich American or European, many people live in what would be considered a poor country. They might have a core2duo if very lucky. The entitlement on this website is getting out of hand.
- p1necone 7y ago
  Is there any data out there on this?
  - thedaemon 7y ago
    https://www.worldatlas.com/articles/the-poorest-countries-in-the-world.html https://www.worldatlas.com/articles/the-poorest-countries-in...
- vmchale 7y ago
  But why is Rust a problem there? Surely it is not fundamentally incompatible with 32-bit architectures?
- heavenlyblue 7y ago
  You will get it in a few years when you buy it cheap used from Americans and Europeans?

smolder 7y ago

The compiler performance may be a perfectly valid reason not to use Rust. Don't mistake the frequent Rust articles for the whole world moving to Rust. It's more like a few excited pioneers exploring its use cases and doing foundational work. Besides, if it helps other people build more stable, secure, or better performing software tools for you to use, isn't that good, even if you don't use it directly yourself?

tracker1 7y ago

First, rust provides safety checks you don't get in C. Second, the only way you'd improve compiler performance via C conversion would bypass these checks. Third, transpiling through C without these safety checks loses the point of rust in the first place. The fact is, that there are a great many bugs in the wild that never would have happened in idiomatic rust in the first place. Yes, there is additional overhead to compiling. By comparison, if you use static code analysis on your C/C++ code there is additional overhead, and even then a greater chance of security bugs slipping by compared to rust. In the end, used server hardware is relatively cheap in most of the world, which does pretty well with this type of code. There are a lot of people using mid-upper range x86 hardware and even to cross-platform compile to lower end arm64 support. At some point, it's less worth maintaining legacy hardware either for pragmatic and/or practical reasons. Rust was started well after x64 and other 64-bit hardware was in the wild, and 32-bit hardware was for the most part no longer being produced. Supporting such systems is work that practically speaking is less valuable to most people. As someone that really likes the old DOS based BBS software and related tech, and even supports Telnet BBSes today, I don't always like seeing this left behind to some extent. Last year, a large portion of the community blew up when 32bit was going to be dropped from Ubuntu, mainly because of the need required by wine and the gaming community. This isn't about supporting 10+ year old apps and programs in an emulated environment... this is about porting existing code in an automated enough way to improve stability and support-ability over time by leveraging a safer language.

AceJohnny2 7y ago

> Perhaps the Rust team should make their compiler work on reasonable resources, like 32 bit processors Rust compiles for and runs on STM32, a 32-bit microcontroller: https://docs.rust-embedded.org/discovery/ https://docs.rust-embedded.org/discovery/ And here's an index of supported embedded hardware: https://github.com/rust-embedded/awesome-embedded-rust#driver-crates https://github.com/rust-embedded/awesome-embedded-rust#drive...

monocasa 7y ago
He's saying for running the compiler, not for the compilation target I think.
- heavenlyblue 7y ago
  Then you can compile the compiler for that platform, no? That being said you would need to implement the basics of OS routines, but it should not be too hard
  - monocasa 7y ago
    Not if the compiler can't fit in memory. And rustc has problems fitting non trivial projects in 2GB of RAM.
andai 7y ago
> Perhaps the Rust team should make their compiler work on reasonable resources, like 32 bit processors >Rust compiles for and runs on STM32, a 32-bit microcontroller Cool, but it can't run the compiler, right? I think that's what GP meant.
- sedatk 7y ago
  I wouldn't call 32-bit processors reasonable anymore. Maybe a decade ago, yes. 64-bit is the norm now. It doesn't make sense to demand 32-bit support.

elihu 7y ago

Poor computer security poses an existential threat to modern civilization. Slow-ish compile times do not.

hinkley 7y ago
I'd heard that the Rust compiler can't compile itself on a 32 bit machine with maxed out RAM. I know there have been some changes to shrink memory usage for a bunch of data types in Rust but it's not clear if that has changed this limitation. I'm trying to learn Rust now, and one of my eventual goals is to look into heap analysis of the compiler, because I agree this is some bullshit. I want to run stuff on ARM eventually and cross compilation and transfer don't sound like my idea of a good time.
- steveklabnik 7y ago
  This is not entirely a rustc issue; LLVM is a huge part of this as well. Sometimes, some steps need more than four gigs of RAM. loc says that rustc has 1.4 million lines of Rust, and LLVM has 5 million of C++. It's just a huge project. In the past, people have reported these things, and we've tried to fix or help where possible; see the discussion on https://github.com/rust-lang/rust/issues/60294 https://github.com/rust-lang/rust/issues/60294 for example.
- estebank 7y ago
  You would only need cross compilation of your project is as big as rustc, but if it were you would likely want the fastest available machine at your disposal and a lot of effort is poured into making cross compilation as painless as possible. Making rustc compilable in a 32bits host might be a good idea, but it is far from a priority. If that is a deal breaker, as it is for OpenBSD for example, Rust is certainly a language that you should look at in the short term.

antpls 7y ago

> Not everyone has a multi-gigahertz, multi-core, multi-gigabyte computer to develop in Rust. Even low-end Android phones have multi-gigahertz, multi-core, multi-gigabyte memory, so actually, many people have that in their pockets

p1necone 7y ago

> "multi-gigahertz, multi-core, multi-gigabyte" Unless you're talking about people holding on to hardware from 20+ years ago then yes - basically everyone with a computer, or a mobile phone has something that fits that classification. People complain about Rust having long compile times, but I doubt it would be unusably bad even on something like a core 2 duo.

damnyou 7y ago

Rust trades off compile time performance for runtime correctness and performance. Far more people run code than compile it.

imtringued 7y ago

I'm not working with Rust but I just tried a quick benchmark by compiling a random project. git clone https://github.com/hyperium/hyper https://github.com/hyperium/hyper Full Build: time cargo build (1 min 42 seconds without download) (349K LOC total [0]) Recompile: time cargo build (2 seconds) (around 18k LOC) I don't see the problem. The full build also includes all the 53 dependencies. So we are talking about a compilation speed of about 3.5k lines/s on a dual core 11" laptop from 2017 with turbo boost disabled. I've personally worked on C++ projects where changing a single header can cause 5 minutes of compilation on an incremental build. Any slowdowns you have experienced may have been caused by a specific library or project. [0] according to cloc ~/.cargo/registry/src/github.com-1ecc6299db9ec823/