[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.

[lelanthran]

> 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.

Yeah, and we had CORBA. Gnome was originally not a DE - the acronym stood for Gnu Network Object Model Environment or similar.

I programmed in CORBA in the 90s. Other than being slower than a snail on weed, I liked it just fine. Maybe it's time for a resurgence of something similar, but without requiring that calls work across networks.

[pjmlp]

That is why platforms like Common Language Runtime exist, not only COM.

CLR was going to be the COM Runtime+, and idea was reborn again as Windows team with their anti-.NET bias decided to redo Longhorn in C++, with WinRT.

"Turning to the past to power Windows’ future: An in-depth look at WinRT"

https://arstechnica.com/features/2012/10/windows-8-and-winrt...

It is also how Android IPC and Apple's XPC kind of get into the picture.

The elephant in the room is that FOSS OSes hardly embrace such solutions.

[zozbot234]

You'll find that all of these languages ultimately build FFI on top of C ABI conventions, though Swift's own internally stable ABI uses a lot of alloca() to place dynamically sized objects on the stack, in a way that's somewhat unidiomatic (the Rust folks are trying to back out of their alloca() equivalent). You can even interface to COM from pure C.

[imtringued]

Just in case someone gets funny ideas: GObject is pretty bad. Don't use it for FFI.

[squeefers]

> We should be aiming for a safe cross language ABI.

now to simply get everyone to stop what theyre doing so they can rewrite their c code into this new language, shouldnt be too hard i imagine