[pizlonator]

Here's the chasm I want to see Rust cross:

Dynamic linking with a safe ABI, where if you change and recompile one library then the outcome has to obey some definition of safety, and ABI stability is about as good as C or Objective-C or Swift.

Until that happens, it'll be hard to adopt Rust in a lot of C/C++ strongholds where C's ABI and dynamic linking are the thing that enables the software to get huge.

[elteto]

> Until that happens, it'll be hard to adopt Rust in a lot of C/C++ strongholds where C's ABI and dynamic linking are the thing that enables the software to get huge.

Wait, Rust can already communicate using the C ABI. In fact, it offers exactly the same capabilities as C++ in this regard (dynamic linking).

[pizlonator]

That's an unsafe ABI.

[jjmarr]

C++ ABI stability is the main reason improvements to the language get rejected.

You cannot change anything that would affect the class layout of something in the STL. For templated functions where the implementation is in the header, ODR means you can't add optimizations later on.

Maybe this was OK in the 90s when companies deleted the source code and laid off the programmers once the software was done, but it's not a feature Rust should ever support or guarantee.

The "stable ABI" is C functions and nothing else for a very good reason.

[pizlonator]

I think if Rust wants to evolve even more aggressively than C++ evolves, then that is a chasm that needs to be crossed.

In lots of domains, having a language that doesn't change very much, or that only changes very carefully with backcompat being taken super seriously, is more important than the memory safety guarantees Rust offers.

[dpc_01234]

What's the stat of single-compiler version ABI? I mean - if the compiler guaranteed that for the same version of the compiler the ABI can work, we could potentially use dynamic linking for a lot of things (speed up iterative development) without committing to any long term stable API or going through C ABI for everything.

[nicoburns]

I think the way to fix this is:

1. Have the stable ABI be opt-in similarly to how the C ABI is opt-in in Rust (`#[repr(stable)]` or similar)

2. Have the stable ABI be versioned. So it would actually be `#[repr(stable_2026)]` or whatever

[pjmlp]

The big question is does Rust want to play being adopted by those vendors, or it would leave them alone with languages that embrace native libraries.

[lelanthran]

> Here's the chasm I want to see Rust cross:

That's not important. What I want to see is the Rewrite-it-in-Rust movement move towards GPL.

GPL is pro-user. MIT is pro-business.

In their zeal to convert, they are happily replacing pro-user software with pro-business software. Their primary goal is to convert, not to safeguard.

If they shifted their goal from spreading Rust to protecting users, I'd be a lot happier about the community.

[bayindirh]

> In their zeal to convert, they are happily replacing pro-user software with pro-business software.

This is one of the two main reasons I'm not using Rust. Second reason is being addressed by gccrs team, so I have no big gripes there, since they are progressing well.

[bigstrat2003]

There is absolutely nothing "pro-business" about permissive licenses. People choose permissive licenses for all kinds of reasons. For example, I personally use them because I believe they are more free and thus more in line with my values. You shouldn't project unsubstantiated statements onto people's motives like this.

[a456463]

Yup. Work hand in hand with FSF. Use GPLv3. No. it is about fat binaries that are just blobs without any introspection and ownership.

[choeger]

That would be great, but Rust relies on compile-time monomorphization for efficiency (very much like C++, if you consider templates polymorphic functions/classes).

This means that any Rust ABI would have to cater for link-time specialization. I think this should be doable, but it would require a solution that's better than just to move the code generation into the linker. Instead, one would need to carefully consider the usage of the "shape" of all parameters of a function.

[hyperman1]

I wonder if we look at it from a too narrow perspective. We use the C ABI because it's the only game in town. We should be aiming for a safe cross language ABI. I'd love to make Rust, C, PHP, Swift, Java and Python easily talk to each other inside 1 process.

It should extend the C ABI with things like strings, arrays, objects with a way to destruct them, and provide some safety guarantees.

As an example, the windows world has COM, which is at the core pretty reasonable for its design constraints, even if gnarly sometimes.

[ahartmetz]

Dynamic linking is also great for compile time of debug builds. If a large library or application is split up into smaller shared libraries, ones unaffected by changes don't need to be touched at all. Runtime dynamic linking has a small overhead, but it's several orders of magnitude faster than compile-time linking, so not a problem in debug builds.

[PaulDavisThe1st]

for developer turnaround time, it is huge. we explicitly do not statically link Ardour because as developers we are in the edit-compile-debug cycle all day every day, and speeding up the link step (which dynamic linking does dramatically, especially with parallel linkers like lld) is a gigantic improvement to our quality of life and productivity.

[eptcyka]

The C ABI can already be used, it comes with all the existing safety guarantees that C will provide. Isn’t this as good as C?

[pizlonator]

It is as good as C.

It's also as bad as C.

I'm saying that the chasm to cross is a safe ABI.

[ozgrakkurt]

I found c ABI a bit too difficult in rust compared to c or zig. Mainly because of destructors. I am guessing c++ would be difficult in a similar way.

Also unsafe rust has always on strict-aliasing, which makes writing code difficult unless you do it in certain ways.

Having glue libraries like pyo3 makes it good in rust. But that introduces bloat and other issues. This has been the biggest issue I had with rust, it is too hard to write something so you use a dependency. And before you know it, you are bloating out of control

[ahartmetz]

Not really. The foreign ABI requires a foreign API, which adds friction that you don't have with C exporting a C API / ABI. I've never tried, but I would guess that it adds a lot of friction.

[pjmlp]

Indeed, Victor Ciura from Microsoft DevDiv has several talks on how this is currently an adoption problem at Microsoft.

They have been working around it with DLLs, and COM/WinRT, but still the tooling isn't ideal.

[rhdunn]

COM is interesting as it implements interfaces using the C++ vtable layout, which can be done in C. Dynamic COM (DCOM) is used to provide interoperability with Visual Basic.

You can also access .NET/C# objects/interfaces via COM. It has an interface to allow you to get the type metadata but that isn't necessary. This makes it possible to e.g. get the C#/.NET exception stack trace from a C/C++ application.

[cryptonector]

Eh, some people can work on moving to Rust, while others work on adding dynamic linking to Rust.

Or maybe we can some how get used to living with static linking. (I don't think so, but many seem to think so in spite of my advice to the contrary!)

Another possibility is to use IPC as the dynamic linking boundary of sorts, but this will consume lots more memory, and as is stated elsewhere in this thread, memory ain't cheap no more.