Language design graveyard is full of improved C attempts, because the problem is not technical, rather it can only be properly solved through change of generations.

Microsoft, Apple, Google have the luxury to impose moving away from C on their platforms.

On other platforms you have developers that won't touch any kind of Safe C even at gun point.

That’s why LLVM is such a great idea - any llvm language can interoperate with any other, within the same binary, with no overhead. Apple isn’t throwing away their C code any time soon either. LLVM provides a smooth upgrade path via mixed language binaries.

I suspect that the move to swift would never have happened without LLVM. And I wouldn’t be surprised if llvm’s cross language compatibility was specifically attractive to Apple because it let them have their cake and eat it too - write a new language but keep legacy C code whenever that’s the best option.

> That’s why LLVM is such a great idea - any llvm language can interoperate with any other, within the same binary, with no overhead.

I don't believe LLVM provides a stable cross language ABI, and AFAIK languages just use regular FFI (via the C ABI) to communicate with one another, regardless of them being implemented on LLVM or not.

> I don't believe LLVM provides a stable cross language ABI, and AFAIK languages just use regular FFI (via the C ABI) to communicate with one another

Provided the compilers generate compatible versions of LLVM IR, then cross-language calls can be done at the IR level. See github.com/Keno/Cxx.jl

IIUC Swift already uses clang to load module maps in order to expose and call Objective-C, and they plan to do something similar with C++ (no link handy but I think there is an issue or enhancement proposal about it).

Yeah, Swift’s C interop goes further than most typical FFIs because it actually calls into Clang internals to read headers, lay out structs and form calls. C and Objective-C types, functions and methods are mapped to Swift definitions, by directly looking at the Clang AST.

> C ABI

Is there really such a thing? I thought the ABI was dependent on the operating system and compiler.

I agree that C is unique in it's ability to generate programs that can be interfaced with from any language. This also seems to apply to older languages like Fortran and Pascal, for some reason. Higher level languages are an ABI nightmare; seriously doubt anyone will ever dynamically link against a C++ library at runtime and call a method on a C++ object from any language that isn't C++.

1. As someone says, LLVM does not have a cross-language ABI, so no, it's not as easy as you think. It makes some things nicer, some things harder.

2. Prior to LLVM, there were much more complete attempts at this (that were even more successful, actually!)

As the siblings have mentioned, llvm doesn't really do this. What does, though, are the jvm and .net, although those aren't really oriented towards low-level c programming.

It is a great idea, but not an innovative one, already PL/8 for IBM RISC research used a similar approach.

My guess is that a lot of the C hold-outs will never switch to another language. C represents the siren's call for them: the best performance, requires skilled handling, no seatbelts, stable definition.

A lot of C's endurance is related to programmer psychology, so it would be futile to design a better C.

C++, Rust, Go, Java will continue to drain the pool of C developers until it's only used for maintenance of existing projects.

This is why it's extremely irksome to see people recommend mixing C and e.g. Python for speed, or other such Frankenstein's monsters - it's just prolonging the agony of whoever will maintain that.

C still represents the closest approximation of what is happening on a chip, quasi-atomic operations acting on finite resources like registers, memory, and I/O. Even if you don't know assembly, you can reasonably understand what various chips will do with your C code, especially low level C code that occasionally dips into assembly (e.g., handling interrupts or chip-level atomic operations).

Rust, Go, and Java, with their memory management and cross-platform portability, and general non-determinism may eat away at the edge of C, but can never replace it.

I could see them fully replacing C if features like garbage collection and byte-code interpretation were handled at the chip-level, so languages would not have to necessarily deal with them. Could also see it happening if a chip's out-of-order execution was exposed at the language level. That would not necessarily make C worse, but Java may be more adept at handling it.

You've made several points...

1. C is no closer than C++, or Rust (including unsafe) and they're all surprisingly pretty far from the hardware these days... this is visible the most in multi-threading, where high-level C statements are re-ordered by the compiler and even simple C statements like an integer assignment can be split into multiple instructions. Inlining and register allocation is also quite opaque and perhaps best left to the compiler, unless one uses non-standard code to force specific behaviour.

2. Well put: Go and Java were/are eating at the edge of C. Java took serious bites in the past, nowadays they're not really competing much. Today, what might have been a small Linux C program could be a Go program, especially if the performance constraints aren't too tight. Technically speaking, Rust can replace C almost everywhere, it's just that it's a significantly more complex language.

Regarding #1, disagree. In C, a function call is just a request to send the instruction pointer to another point in the memory space. In C, code is treated as data, which is how it's treated in hardware.

C++ introduces virtual functions, and when you make a function call, you're no longer going to a single place in memory, you go to where the class's virtual function table tells you to go, effectively jumping to a memory pointer. This is pretty helpful, but it's an incredibly different way to think about code. A function is no longer a set of instructions in memory, it's a logical representation of functionality.

And yes, I know in C, you can set a variable to a function location, and then jump there, but it's painful to do and you have to do it explicitly, so it doesn't really create an abstraction.

Regarding 2.

I am fully convinced that if Java and .NET had a proper AOT toolchain from day 1, meaning beyond dynamic linking (NGEN) or commercial offerings from 3rd party JDKs, C's influence on FOSS world would have been much less than it achieved to be.

And we would already have achieved an UNIX like stack closer to what Inferno/Limbo was all about.