4 ms·

that's for MCU and yes, as it does not use rust's stdlib. there are lots of embedded systems that run with glibc or musl shared libraries, if rust is used ther

that's for MCU and yes, as it does not use rust's stdlib. there are lots of embedded systems that run with glibc or musl shared libraries, if rust is used there, it will blow up the storage space with just a few executables due to the static stdlibs.

steveklabnik 3y ago
I don’t understand why techniques valid in small spaces aren’t also valid in slightly larger spaces. If you don’t have the budget for the standard library, don’t use it. If you somehow have the budget for glibc and not the rust standard library, call into glibc instead of the rust standard library.
- synergy20 3y ago
  glibc can be shared by 20 c executables. rust stdlib will be bundled with those 20 rust executables, they blow up quickly. mcu does not use stdlib of rust, it uses no-std, c++ has its own nonstdlib as well, on mcu they're similar.
  - steveklabnik 3y ago
    Yes, I understand what you're saying. I am saying that if you find yourself in that situation, don't use the Rust standard library. Your Rust programs can share glibc with your C programs just fine. This isn't a disqualifying situation for Rust. Heck, when you use the Rust standard library, dynamically linking to glibc is the norm!
    - simon_void 3y ago
      maybe OP doen't know about #![no_std] !? You can not (as far as I know) have the Rust std lib as a dll, but you can chose to not use/include the std lib: https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/book/first-edition/using-rust-without-the-standard-library.html https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/sh...
      - steveklabnik 3y ago
        Just FYI, these docs are very old. They’re for rust 1.25.0. Since rust is stable that means they’re still accurate, just not complete.
      - synergy20 3y ago
        of course I knew no_std, it's for MCUs, similar to c++'s nostdlib, I'm comparing rust's stdlib to libstdc++ though, but the former is not shared-lib friendly to say the least.

steveklabnik 3y ago

I don’t understand why techniques valid in small spaces aren’t also valid in slightly larger spaces. If you don’t have the budget for the standard library, don’t use it. If you somehow have the budget for glibc and not the rust standard library, call into glibc instead of the rust standard library.

synergy20 3y ago
glibc can be shared by 20 c executables. rust stdlib will be bundled with those 20 rust executables, they blow up quickly. mcu does not use stdlib of rust, it uses no-std, c++ has its own nonstdlib as well, on mcu they're similar.
- steveklabnik 3y ago
  Yes, I understand what you're saying. I am saying that if you find yourself in that situation, don't use the Rust standard library. Your Rust programs can share glibc with your C programs just fine. This isn't a disqualifying situation for Rust. Heck, when you use the Rust standard library, dynamically linking to glibc is the norm!
  - simon_void 3y ago
    maybe OP doen't know about #![no_std] !? You can not (as far as I know) have the Rust std lib as a dll, but you can chose to not use/include the std lib: https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/book/first-edition/using-rust-without-the-standard-library.html https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/sh...
    - steveklabnik 3y ago
      Just FYI, these docs are very old. They’re for rust 1.25.0. Since rust is stable that means they’re still accurate, just not complete.
    - synergy20 3y ago
      of course I knew no_std, it's for MCUs, similar to c++'s nostdlib, I'm comparing rust's stdlib to libstdc++ though, but the former is not shared-lib friendly to say the least.