3 ms·

1. Operating systems don't ship Rust's stdlib (unlike C's), so such binary would work only on developer's own machine. 2. Rust doesn't want to commit to a stab

by pornel 6y ago

1. Operating systems don't ship Rust's stdlib (unlike C's), so such binary would work only on developer's own machine. 2. Rust doesn't want to commit to a stable ABI yet, so even if an OS wanted to ship libstd, it'd be logistically difficult due to libstd version having to exactly match compiler version.

ahartmetz 6y ago
1. seems like a chicken and egg problem. I'm sure that the Debian developers wouldn't mind shipping it if it made sense (see 2). 2. is a fair point. At this point in Rust's life I see how avoiding binary conpatibility questions makes sense. Is anybody even working on it, though? Otherwise Rust could be making system-provided, dynamically linked libraries almost impossible due to earlier design decisions without consideration for BC.
- est31 6y ago
  > Is anybody even working on it, though? There is no work on MVPs or RFCs for now, but stable ABIs are being discussed currently: https://internals.rust-lang.org/t/a-stable-modular-abi-for-rust/12347 https://internals.rust-lang.org/t/a-stable-modular-abi-for-r...
- zozbot234 6y ago
  > Otherwise Rust could be making system-provided, dynamically linked libraries almost impossible They're very much possible; they're just limited to using the C ABI when interacting with dynamically-linked code. More complex features can be implemented by providing thin wrappers as part of language-specific bindings.
jedbrown 6y ago
As Rust becomes more prevalent in utilities, routine apps, and workflows using process-based parallelism, there will be a memory advantage to using shared libraries so that stdlib only needs to be resident once instead of once for each process. So long as it is packaged so multiple versions can coexist, this would make sense for packagers.
derefr 6y ago
It would still make a lot of sense to dynamically link the particular libstd used for the compilation—and ship it alongside the package—if one wanted to ship a package containing many executables, the way that e.g. ImageMagick works.
- wnoise 6y ago
  I thought that in recent times ImageMagick acted like busybox, with all the executables symlinked to one master one, and dispatching functionality based on name. Certainly that's the way the fork GraphicsMagick works.

by pornel 6y ago

ahartmetz 6y ago

1. seems like a chicken and egg problem. I'm sure that the Debian developers wouldn't mind shipping it if it made sense (see 2). 2. is a fair point. At this point in Rust's life I see how avoiding binary conpatibility questions makes sense. Is anybody even working on it, though? Otherwise Rust could be making system-provided, dynamically linked libraries almost impossible due to earlier design decisions without consideration for BC.

est31 6y ago
> Is anybody even working on it, though? There is no work on MVPs or RFCs for now, but stable ABIs are being discussed currently: https://internals.rust-lang.org/t/a-stable-modular-abi-for-rust/12347 https://internals.rust-lang.org/t/a-stable-modular-abi-for-r...
zozbot234 6y ago
> Otherwise Rust could be making system-provided, dynamically linked libraries almost impossible They're very much possible; they're just limited to using the C ABI when interacting with dynamically-linked code. More complex features can be implemented by providing thin wrappers as part of language-specific bindings.

jedbrown 6y ago

As Rust becomes more prevalent in utilities, routine apps, and workflows using process-based parallelism, there will be a memory advantage to using shared libraries so that stdlib only needs to be resident once instead of once for each process. So long as it is packaged so multiple versions can coexist, this would make sense for packagers.

derefr 6y ago

It would still make a lot of sense to dynamically link the particular libstd used for the compilation—and ship it alongside the package—if one wanted to ship a package containing many executables, the way that e.g. ImageMagick works.

wnoise 6y ago
I thought that in recent times ImageMagick acted like busybox, with all the executables symlinked to one master one, and dispatching functionality based on name. Certainly that's the way the fork GraphicsMagick works.