4 ms·

> dynamic linking isn't really supported This is one of my few big gripes with Rust too, but it should be pointed out that it's dynamic linking with other Rust

by gspr 4y ago

> dynamic linking isn't really supported This is one of my few big gripes with Rust too, but it should be pointed out that it's dynamic linking with other Rust code that isn't really supported. Dynamic linking with e.g. C libraries is a breeze.

zozbot234 4y ago
You can of course link with Rust code that exports a pure C ABI. Such code works just like a shared library coded in C/C++.
ok123456 4y ago
I'm not sure how useful that would be since people pin specific version of libraries with Rust. They don't care about ABI stability so even if you could just update links to a library, the interface would be horribly broken. Part of the discipline of writing C++ and C libraries is writing around a stable interface, that you can link against. In C++ that means using the pImpl pattern.
- gspr 4y ago
  > They don't care about ABI stability so even if you could just update links to a library, the interface would be horribly broken. Which is, of course, the actual gripe we're discussing. The lack of dynamic linking is just a consequence.
  - ok123456 4y ago
    If there's an exploit/problem in, say, a crypto library, Rust's ecosystem seems less resilient. Instead of just updating the library system wide, you have to get everyone to rebuild their applications with a safe version of the library (if it's even possible). This has happened and will absolutely happen again. Just being "memory safe" will not prevent protocol errors, bad IVs, preventing timing attacks, or the other subtle things involved when doing cryptography on the wider internet.
    - brundolf 4y ago
      On the other hand- crates.io + the toolchain make it way easier for fixes to propagate outward into the ecosystem, and then for new builds to be created with them (even for multiple platforms at once) There's a huge list of tradeoffs between dynamic and static linking, and Rust is betting that in today's world, with modern tooling, internet availability, hardware speeds, and memory size, the benefits of static linking outweigh the costs. I guess time will tell But- traditionally Linux has really leaned into the opposite approach, so it'll be interesting to see how that dissonance plays out, and whether one or both is forced to compromise, as Rust gets more embedded in the Linux ecosystem
      - gspr 4y ago
        > On the other hand- crates.io + the toolchain make it way easier for fixes to propagate outward into the ecosystem, and then for new builds to be created with them (even for multiple platforms at once) As a Rust fan who subscribes to the classical Linux distro model (and even exclusively gets his Rust crates from there), I disagree. What you suggest comes with a cost, namely having to accept software in constant flux. To me, that cost in unacceptably big. I write a bit more about this gripe here: https://news.ycombinator.com/item?id=32925491 https://news.ycombinator.com/item?id=32925491
    - gspr 4y ago
      I wholeheartedly agree. It's the one worry I have with a language that I otherwise love. (Of course the problem is technically hard, or possibly unsolvable, so I don't blame the Rust folks for its existence.)

by gspr 4y ago

zozbot234 4y ago

You can of course link with Rust code that exports a pure C ABI. Such code works just like a shared library coded in C/C++.

ok123456 4y ago

I'm not sure how useful that would be since people pin specific version of libraries with Rust. They don't care about ABI stability so even if you could just update links to a library, the interface would be horribly broken. Part of the discipline of writing C++ and C libraries is writing around a stable interface, that you can link against. In C++ that means using the pImpl pattern.

gspr 4y ago
> They don't care about ABI stability so even if you could just update links to a library, the interface would be horribly broken. Which is, of course, the actual gripe we're discussing. The lack of dynamic linking is just a consequence.
- ok123456 4y ago
  If there's an exploit/problem in, say, a crypto library, Rust's ecosystem seems less resilient. Instead of just updating the library system wide, you have to get everyone to rebuild their applications with a safe version of the library (if it's even possible). This has happened and will absolutely happen again. Just being "memory safe" will not prevent protocol errors, bad IVs, preventing timing attacks, or the other subtle things involved when doing cryptography on the wider internet.
  - brundolf 4y ago
    On the other hand- crates.io + the toolchain make it way easier for fixes to propagate outward into the ecosystem, and then for new builds to be created with them (even for multiple platforms at once) There's a huge list of tradeoffs between dynamic and static linking, and Rust is betting that in today's world, with modern tooling, internet availability, hardware speeds, and memory size, the benefits of static linking outweigh the costs. I guess time will tell But- traditionally Linux has really leaned into the opposite approach, so it'll be interesting to see how that dissonance plays out, and whether one or both is forced to compromise, as Rust gets more embedded in the Linux ecosystem
    - gspr 4y ago
      > On the other hand- crates.io + the toolchain make it way easier for fixes to propagate outward into the ecosystem, and then for new builds to be created with them (even for multiple platforms at once) As a Rust fan who subscribes to the classical Linux distro model (and even exclusively gets his Rust crates from there), I disagree. What you suggest comes with a cost, namely having to accept software in constant flux. To me, that cost in unacceptably big. I write a bit more about this gripe here: https://news.ycombinator.com/item?id=32925491 https://news.ycombinator.com/item?id=32925491
  - gspr 4y ago
    I wholeheartedly agree. It's the one worry I have with a language that I otherwise love. (Of course the problem is technically hard, or possibly unsolvable, so I don't blame the Rust folks for its existence.)