3 ms·

> Instant boot time. Because rust is statically compiled, there's no runtime startup or anything involved with it. From dead to alive is pretty much instant.

> Instant boot time. Because rust is statically compiled, there's no runtime startup or anything involved with it. From dead to alive is pretty much instant. Dynamic linkage is not the slow part of application startup. The slow part (for applications which are slow) is almost always the gathering of non-compiled assets from disk. IMO, the lack of dynamic linkage is Rust's #2 weak point, second only to slow build times.

cogman10 6y ago
Sorry, that wasn't a dynamic linking dig, but more of a JIT dig. I agree that rust would be better with dynamic linking. It sucks that you have to build everything when you build one thing :(. The issue I was specifically thinking of is how slow an untuned JVM can be for startup times and to get to peak performance (It HAS gotten better, but is nowhere near as fast as rust or even python). The default for these JITed languages is to pass everything through a non-optimized code path and only optimize later when the various methods are exercised enough. Rust has an advantage here in that it doesn't do any sort of runtime analysis to improve performance. It simply is as fast as it always will be.
zozbot234 6y ago
You can use dynamic linking with Rust. You just have to stick to the C ABI when interfacing w/ shared objects, because there is no stable Rust-specific ABI.
- brandmeyer 6y ago
  (!) I was under the impression that you could not develop a shared library in Rust even if you exposed a C ABI.
  - deleted 6y ago
    [deleted]
  - steveklabnik 6y ago
    A Rust artifact being used as a dynamically loaded library within a Ruby process via a C ABI is one of the very first, if not maybe first ever, production uses of Rust. You've been able to do this for a long time. That being said, it is not simple to say, take a binary Rust Cargo project and say "please dynamically link all the crates it uses" or something like that. But if you want a dynamic library to be used by something else? First-class support for that use case exists.

cogman10 6y ago

Sorry, that wasn't a dynamic linking dig, but more of a JIT dig. I agree that rust would be better with dynamic linking. It sucks that you have to build everything when you build one thing :(. The issue I was specifically thinking of is how slow an untuned JVM can be for startup times and to get to peak performance (It HAS gotten better, but is nowhere near as fast as rust or even python). The default for these JITed languages is to pass everything through a non-optimized code path and only optimize later when the various methods are exercised enough. Rust has an advantage here in that it doesn't do any sort of runtime analysis to improve performance. It simply is as fast as it always will be.

zozbot234 6y ago

You can use dynamic linking with Rust. You just have to stick to the C ABI when interfacing w/ shared objects, because there is no stable Rust-specific ABI.

brandmeyer 6y ago
(!) I was under the impression that you could not develop a shared library in Rust even if you exposed a C ABI.
- deleted 6y ago
  [deleted]
- steveklabnik 6y ago
  A Rust artifact being used as a dynamically loaded library within a Ruby process via a C ABI is one of the very first, if not maybe first ever, production uses of Rust. You've been able to do this for a long time. That being said, it is not simple to say, take a binary Rust Cargo project and say "please dynamically link all the crates it uses" or something like that. But if you want a dynamic library to be used by something else? First-class support for that use case exists.