4 ms·

there is another key difference between rust and c++, rust by default bundles its stdlib into the executable, which make each executable kind of a static binary

there is another key difference between rust and c++, rust by default bundles its stdlib into the executable, which make each executable kind of a static binary, they add up fast. c++ uses shared libraries, smaller in size for the whole system, and, you can upgrade a library separately too. on embedded systems where storage space is restricted, rust is simply a no-go.

skywal_l 3y ago
Use LTO if that's a problem. [profile.release] # A profile to try to minimize the size panic = "abort" # Abort on Panic strip = true opt-level = "z" # Optimize For Size lto = true # Enable Link Time Optimization (LTO) codegen-units = 1 # Reduce Parallel Code Generation Units to Increase Optimization
- synergy20 3y ago
  it helps, I tried 'how to make rust the minimal in size', but still, it's like 10x of the size comparing to c++ with shared libraries.
steveklabnik 3y ago
You absolutely can get Rust codegen down to as small as you’d ever need: https://news.ycombinator.com/item?id=34032824 https://news.ycombinator.com/item?id=34032824
- synergy20 3y ago
  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
eternityforest 3y ago
Flash storage is getting cheap. There is some places where it matters.... but on everything else.... I am really not a fan of dynamic linking. Linux has proven for a very long time that if you have 100 programs, and they each have 100 dependencies, you'll probably see an occasional issue related to incompatibility. It seems like it's suited to the mindset of unique systems maintained by sysadmins, with every app being a part of the system, quite possibly built locally just for your task. The modern way seems to be disposable installs that cab be recreated automatically if some probably-not-worth-fixing thing happens, made of reusable multipurpose software made by people who have never heard of your application, and a bit of local code, which might be intended to someday become one of those mega-frameworks. Even windows used to always have hassles with some visual C++ runtime or other. Although the standard library of C isn't a big issue since it's not in the habit of breaking things, but I'd imagine Rust might want to make bigger changes since it's so new.
ostenning 3y ago
All embedded applications and libraries can be declared with no_std, removing the std dependency and heap allocation. Shared libraries are also possible.
- synergy20 3y ago
  well without stdlib, there is not much I can do on non-mcu devices it's like I have c++ but no libstdc++ for a smart tv device development
hdjdkdbdbe 3y ago
You have the ability to remove the stdlib if needed...

skywal_l 3y ago

Use LTO if that's a problem. [profile.release] # A profile to try to minimize the size panic = "abort" # Abort on Panic strip = true opt-level = "z" # Optimize For Size lto = true # Enable Link Time Optimization (LTO) codegen-units = 1 # Reduce Parallel Code Generation Units to Increase Optimization

synergy20 3y ago
it helps, I tried 'how to make rust the minimal in size', but still, it's like 10x of the size comparing to c++ with shared libraries.

steveklabnik 3y ago

You absolutely can get Rust codegen down to as small as you’d ever need: https://news.ycombinator.com/item?id=34032824 https://news.ycombinator.com/item?id=34032824

synergy20 3y ago
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

eternityforest 3y ago

Flash storage is getting cheap. There is some places where it matters.... but on everything else.... I am really not a fan of dynamic linking. Linux has proven for a very long time that if you have 100 programs, and they each have 100 dependencies, you'll probably see an occasional issue related to incompatibility. It seems like it's suited to the mindset of unique systems maintained by sysadmins, with every app being a part of the system, quite possibly built locally just for your task. The modern way seems to be disposable installs that cab be recreated automatically if some probably-not-worth-fixing thing happens, made of reusable multipurpose software made by people who have never heard of your application, and a bit of local code, which might be intended to someday become one of those mega-frameworks. Even windows used to always have hassles with some visual C++ runtime or other. Although the standard library of C isn't a big issue since it's not in the habit of breaking things, but I'd imagine Rust might want to make bigger changes since it's so new.

ostenning 3y ago

All embedded applications and libraries can be declared with no_std, removing the std dependency and heap allocation. Shared libraries are also possible.

synergy20 3y ago
well without stdlib, there is not much I can do on non-mcu devices it's like I have c++ but no libstdc++ for a smart tv device development

hdjdkdbdbe 3y ago

You have the ability to remove the stdlib if needed...