Conversation

First off: we should look at languages like Swift, Zig, Python, maybe even Go or C++, and find a better set of primitives to work with. I think there is a common set of features that wouldn't have everything, but would prevent falling back to the nuts and bolts of C.

Second: we shouldn't try to make the whole language follow this ABI. It should be relegated to API boundaries that are meant for FFI. This way we can keep language-specific optimizations in the normal case, and only pay a static ABI cost at the API surface area.

Third: the ABI should have the concept of semver baked in, or at least a monotonically increasing version number. It should be expected that this ABI increases regularly (1/months-years).

Third again: Compilers should be able to support emitting multiple different versions of this new ABI, based on a sliding window of version support. Linkers/Dynamic linkers should learn how to polyfill mismatched version numbers

Fourth: The ABI should encode some basic concept of ownership/lifetimes, even if the language only supports cloning/copying out of the borrow.

Fifth: The ABI should include the ability to encode information about types and layouts, not just function names. This should be used at compile/runtime to provide type information. Compilers should be able to import ABI libraries directly, or provide codegen tools to get headers

Sixth: The ABI should include a standard for enough introspection to at least get type and signature information for functions and data structures, both for the compiler and for humans. Ideally, you could include doc comments as a first class citizen as well.