Hacker News Reader

Comment by CameronNemo | Hacker News Reader

C is also much better at dynamically linking, and results in much smaller binaries. Still not good justification for flatpak. Or crun (the reimplementation of runc in C) for that matter. The Red Hat crew has a problem with their reliance on C, Python, and Go. They need something like Rust (or even Vala, which does ARC from what I can tell) in their arsenal.

View on HN

It's rather easy to dynamically link something that's not polymorphic.

What exactly is the issue with Rust and dynamic linking? Is it that it can't dynamically load Rust interfaces? There's nothing wrong with linking plain old symbols from shared objects in Rust.

Rust has no stable ABI contrary to C and also support much higher concept like polymorphism or high order functions which are much harder to represent in a simple ABI.

Real dynamic linking on that (dlopen-style) can be a real nightmare, specially between compiler versions.

You can also add that Rust do not have a runtime, which is in many cases an advantage, but also tend to make libraries bigger.

Similar to C++ though, e.g. explosions of template expansions, you don't have to use those higher-level and harder-to-keep-concise features. Other fancy languages have stable ABIs, it's not impossible, nor does it require that it's complex to use.

Though the average one is probably harder, yes. I'd wager that it's mostly lack of care or motivation though, made a bit worse by common language features.

> Similar to C++ though, e.g. explosions of template expansions, you don't have to use those higher-level and harder-to-keep-concise features.

C++ has a stable ABI. Fragile, but stable. Or doing things like updating libQt on your Linux distribution without recompiling half of the world would be close to impossible :)

This is a relatively new feature and there have been one or two ABI breaks since they thought it was done that required recompiling half the world. I think it's been solid for at least most of the last decade though so... stable enough? I'm not sure if there is an actual spec somewhere though, certainly not a proper one from a standards body. It's just "whatever GCC or MSVC do on that OS/CPU combo" and those two happen to have stopped changing the ABI every compiling release at some point. They're both at least based on the relatively well specified Itanium C++ ABI though so that helps.

C++ is also older than Rust by, oh... a few years.

I'm not aware of any plan to not stabilize Rust's ABI, it just hasn't happened yet. It's completely fair to label that a deal-breaker for using Rust, but trying to draw a hypothetical box around it with the label "its ABI will be difficult to create and/or use" seems a bit unwarranted.

Rust can create dynamic libraries that import and export symbols using the C ABI, so it is not worse than C in such a comparisons, since it can do exactly the same thing as C.

Are there any examples of libraries that are implemented in this way?

https://news.ycombinator.com/item?id=23290506

https://coaxion.net/blog/2017/09/exporting-a-gobject-c-api-f...

https://hsivonen.fi/modern-cpp-in-rust/

http://hansihe.com/2017/02/05/rustler-safe-erlang-elixir-nif...

Recently there’s been a renewed discussion about how to make a stable, modular ABI for Rust: https://internals.rust-lang.org/t/a-stable-modular-abi-for-r...

Reply on news.ycombinator.com