I always thought that the runtime or runtime system is the set of instructions that a compiler generates to execute the source code. This includes a garbage collection system, setting up and destroying stackframes and passing arguments for function calls. So by this definition Tokio is not a runtime. It is a library and when it gets compiled the compiler inserts instructions within the functions defined by tokio that are part of the runtime system. e.g. managing stackframes.
Runtime is a general term for shared supporting code needed for features that can't be completely handled at compile time.
It's a broad term, and doesn't mean any specific way of implementing or using that runtime. It doesn't have to be built-in into the language.
For programming languages, a runtime can often mean a garbage collector, but it's just a one example of many. C has a bit of a runtime for setting up args for main, handling stdio, etc. Rust's standard library and panic unwinding code can be considered a runtime too.
In case of futures, having a runtime means there's a bunch of code needed to poll the futures when they're executed, and your program must have such code — available at run time — to be able to use futures.
I'd be interested to know where that definition of runtime came from. Under that definition all programs would be runtimes. Even code that is written in assembler or raw hex instructions would be runtimes. It would have no meaning.
I always argue that languages like C and Rust do not have a runtime, there is no other code running, behind the scenes, than that which is generated from your source code.
That is in contrast to languages like Python and Java that generally rely on an interpreter to run them and/or require a garbage collector running along side them to keep memory clean.
Yes C, Rust and many other compiled to native code languages have some code that does not appear in your source to set things up before they run your code and clean things up when it ends. But that is not running at run-time.
Of course sometimes your program will be run by some operating system and that operating system has code for allocating memory, performing I/O etc. Arguably such an OS is the runtime of your program, providing it with facilities it needs as it runs. But an OS is no part of the C or Rust language definition and I have never heard an OS described as a runtime.
So what about Tokio and other async so called "runtimes" in Rust. Well async in Rust requires some code, running behind the scenes at run time, to juggle your async tasks, spread tasks over the cores of your machine, handle async I/O etc. Typically none of that code exists in the source you have written in your program. Rather it is in the Tokio crate or whichever. I guess there is a good case for calling these things "runtimes".
I would not consider it to be a run time. It''s bunch of methods and functions you can use if you like. Or not. I have an ever growing Rust program here that does not use the standard library. Rust itself does not have a runtime.
I think it depends on whether it is included/needed by default or not. The linked answer uses present at runtime.
a common C runtime consists of the loader (which is part of the operating system) and the runtime library, which implements the parts of the C language which are not built into the executable by the compiler; in hosted environments, this includes most parts of the standard library
I've always considered it this way: when you're predominantly calling functions from somebody else's code, that code isn't a runtime. When it's predominantly calling your code (e.g. Tokio executors polling your futures, or an interpreter like Python), or running perpetually alongside it (e.g. Java and other GCed languages), that's when it qualifies as a runtime to me.
And yes, there tends to be confusion between the usage of "runtime" meaning "while your code runs", and the meaning we've been discussing. While the two overlap a little bit, I don't think it's worthwhile trying to define one in terms of the other.
That sounds synonymous to "framework". The only difference seems to be that a runtime is associated with a programming language(C, Java, Python…) or its feature(async), whereas a framework is associated with a problem domain.
Yes, I consider the two to be pretty much synonymous. The main difference, I would say, is that frameworks tend to come with more "helpers" (like Tokio with all its little helper bits), where runtimes provide more bare-bones means for interacting with them. But that's by no means "official" terminology, just my own understanding.