[whytevuhuni]

> What's the difference between a standard library and a runtime? In the three decades I've been programming, they've been used interchangeably.

First of all, you're right. But despite its definition I think people tend to look at it differently.

A runtime is generally thought of as a platform on top of which your code runs on; it needs to start first, and it manages your code. Or perhaps it runs in a side thread.

A language that has a runtime is hard to embed into something via just the C ABI, because a function call wouldn't use just the standard platform calling convention; it would have to start that runtime, perhaps marshal the parameters into something supported by that runtime, and then finally the runtime runs your function's code.

Take for example cgo, for which you'd need to start the garbage collector first (among other things), hence why the cgo FFI is expensive. Take as another example an async Rust function, which would require e.g. a Tokio runtime to be started first. Another example is Java, for which you'd have to start the whole JVM first.

A language that has no runtime, or a minimal runtime, can be called via the C ABI directly. All the function needs is to follow the calling convention, and then its code starts running immediately.

This is just my opinion of other people's opinions, I may be wrong.

[pron]

> A runtime is generally thought of as a platform on top of which your code runs on

That's not a well-defined thing.

> A language that has a runtime is hard to embed into something via just the C ABI, because a function call wouldn't use just the standard platform calling convention

But Java can be embedded in native code or embed native code. It has a specified FFI in both directions.

> Take for example cgo, for which you'd need to start the garbage collector first (among other things), hence why the cgo FFI is expensive.

Well, Java doesn't quite work like that, and its (new) FFI is free in most important cases (i.e. same as a non-inlined C-to-C call). Also, "starting the garbage collector" is not well-defined. What "starts" Rust's garbage collector?

I understand what you're trying to get at, but things aren't so simple. There are, indeed, differences especially around JIT vs AOT, but it's not as simple as saying "having a runtime" or not, nor is everything similar in all languages (Rust and C don't work the same vis-a-vis the C ABI, and Java, C#, and Go interop with native code are all quite different from each other).

> A language that has no runtime, or a minimal runtime, can be called via the C ABI directly.

A Java program can easily expose any method via the C ABI to be called directly if the process has been started from Java -- i.e. it's easy for Java code to give native code a function pointer to Java code. Going the other way, i.e. embedding Java in a C program, is somewhat more involved, but even C++'s interop with C, not to mention Rust or Zig, is not always straightforward. Like in Java, certain functions need to be marked as "C-interopable".

[whytevuhuni]

> But Java can be embedded in native code or embed native code. It has a specified FFI in both directions.

Most languages have an FFI, but I am talking specifically about the C ABI and the platform calling convention; or more specifically, about starting from scratch, and what is necessary to do from there until your code can finally run.

Anything more complex than the C ABI is what makes people say there is a runtime. It's some layer between your code and the other language's code, inserted there by your language. There's usually no way to remove it, and if there is, it severely limits the language features you can use.

> What "starts" Rust's garbage collector?

Nothing; it doesn't start unless the function itself wants to start one, and the function can choose which one to start, through your code (rather than what the language's required runtime provides).

> A Java program can easily expose any method via the C ABI to be called directly if the process has been started from Java

In that case, the runtime has already been started, and is being reused.

> Going the other way, i.e. embedding Java in a C program, is somewhat more involved

That part is the most important part, and is generally why people say Rust has a minimal runtime; it can be embedded with very little setup. The code you write starts executing almost immediately. Java calling C may add a management layer on Java's side, but C/C++/Rust/Zig/etc need very little (hence, minimal runtime).

[pron]

> Anything more complex than the C ABI is what makes people say there is a runtime.

But Rust (or Zig, or C++ for that matter) don't use the C ABI, either, except for specifically annotated functions.

> In that case, the runtime has already been started, and is being reused.

True, but I'm trying to say that the notion of "starting" the runtime (or the GC for that matter) is not really well-defined. HotSpot does need to be "started", but, say, Graal Native Image, which is sort of an AOT-compiled, statically linked JVM, isn't really "started".

> Java calling C may add a management layer on Java's side, but C/C++/Rust/Zig/etc need very little (hence, minimal runtime).

In some implementations of Java this may be the case in some situations, yes. I would go further and say that that's the typical case, i.e. if you want to embed the stock HotSpot, you will need to call some initialisation functions.

If that's what's meant by "runtime", then it's mostly correct, but it's more an implementation detail of HotSpot. Even without it there will remain more important differences between C++/Zig/Rust/C and Java, and this matter of "runtime" is not the most interesting aspect. For example, that Java is usually compiled JIT and Rust is usually compiled AOT is a bigger and more interesting difference.

[whytevuhuni]

> But Rust (or Zig, or C++ for that matter) don't use the C ABI, either, except for specifically annotated functions.

Not only that, but Rust, C, Zig also require some setup before their `main()` can start as well.

That is why people say they have a "minimal runtime", rather than "no runtime". There is still a bit of setup there, without which the languages cannot function, or can only function in a limited mode.

Otherwise agreed on all your other points.

[neonsunset]

FWIW Cgo FFI is expensive not because of GC but because Go uses virtual threads (goroutines) and prioritizes the simplicity of runtime implementation. The lower bound of FFI cost in .NET is roughly equivalent to direct not-inlined calls in C, despite the GC support.