Rust is yes to both, although 'the runtime' is disappearing, replaced by just using the system APIs directly (that is, Rust will have no runtime beyond what C/C++ has). The non-Rust code in the main distribution is:
- LLVM for the complier
- hoedown (markdown parser/renderer) for the documentation generator
- miniz for compressing the metadata stored in each library
- a few other tiny wrappers[1] for which I see no reason other than inertia/low-priority for translating into Rust (e.g. there would be no particular build-system benefit to Rustifying them because C/C++ compilers are needed for the other things anyway)
Whoa now, let's not go lumping C and C++ together! C++ has quite a heavier runtime to manage stuff like exceptions and RTTI! (though, to be honest, I don't know what's a C++ program's runtime requirement if compiled with -fno-exceptions, -fno-rtti and the like)
Generally speaking the heavy part of both exceptions and rtti are in codegen (ie. the amount of code generated by the compiler), not in the 'runtime'. Exception jump tables and typeinfo objects are calculated as part of the compile and just referred to at run time.
If you disable rtti and exceptions, the only piece that needs runtime support is global constructors.
I've done it in the past with linker tricks to generate an ELF section with the list of ctor addresses. The asm that calls main (which if you're rolling your own runtime, you probably wrote as well) just calls them all right before it calls main().
I define a language without a runtime as one that can run on bare metal without restricting yourself to a subset of the language. To use C on bare metal, the only thing you can't use is the standard library, which is not a part of the language itself (its not in the grammar, you don't need to make sure to avoid certain keywords). More simply, any program written without using an import needs to work without an operating system under it.
C++ requires runtime support because if you remove the underlying system, it becomes stunted. Keywords like 'new' and 'delete' stop working entirely, and so a program with no imports is not guaranteed to work. Any language with a GC falls under this, obviously. Rust, if I remember right, requires restricting yourself in order to do things like kernel writing.
That's not what I mean. I mean that any C you write will run with no problems as long as it doesn't depend on an outside library. It's not possible to do anything that needs interrupts, IO, or memory without an external library, which if you're that low you're gonna be writing yourself either way. Accessing individual registers is also a special behavior that doesn't really fall under using C, and regardless that totally possible without a runtime (the __asm__ keyword, thats all compiler driven).
If you're going to get so specific as to call the x86 processor a runtime, then there's no point in arguing.
> It's not possible to do anything that needs interrupts, IO, or memory without an external library, which if you're that low you're gonna be writing yourself either way.
That external library is called a runtime in compiler design classes.
> Accessing individual registers is also a special behavior that doesn't really fall under using C, and regardless that totally possible without a runtime (the __asm__ keyword, thats all compiler driven).
The __asm__ keyword is not part of ANSI C, it is a language extension.
Not all C compilers offer support for inline assembly and in fact, a few commercial ones do not.
> If you're going to get so specific as to call the x86 processor a runtime, then there's no point in arguing.
That sounds kind of like what I mean. I consider it having a runtime if anything that can be used without importing the standard library won't work out of the box when you boot a machine to it.
Well, the 'standard library' is a bit of a flexible concept in Rust. We have 'libcore' and 'libstd'. core is what's still usable without any runtime support whatsoever, and std does.
I mean, none of Rust's _features_ don't work without runtime support, but libraries that need tasks (threads) and task unwinding require the runtime. Those are all library features not language features.
Ah ok, interesting. I've been contemplating converting my toy kernel (which doesn't do all that much yet) into Rust, since it doesn't use a GC for everything, could be fun.
For example UNIX effectively provides a certain kind of memory safety to C programs, by isolating them via VM hardware from other C programs and their memory management bugs, which is quite important in practice... calling that a language "runtime" seems appropriate, especially since there are OS architectures that don't even require VM hardware for isolation (Singularity).
You say that the runtime is disappearing. But, if LLVM is being used, then since it provides the JIT, I'd say it is a really big part of the runtime, actually.
The "VM" in LLVM is deceiving (and LLVM actually no longer stands for "low-level virtual machine"), its main use now is as an ahead-of-time optimiser/code-generator for the Clang C & C++ compiler. Rust uses it in this capacity too: optimised native code is emitted at compile time and no JITing is necessary.
Of course, LLVM can be used as a JIT (e.g. what Apple is doing with javascript), but Rust does not use or need it.
> Of course, LLVM can be used as a JIT (e.g. what Apple is doing with javascript)
Even then, assuming you're talking about FTL LLVM is "just" a codegen backend (w/ optimisations) for an existing JIT pipeline, most of the JIT infrastructure is outside LLVM.
- LLVM for the complier
- hoedown (markdown parser/renderer) for the documentation generator
- miniz for compressing the metadata stored in each library
- a few other tiny wrappers[1] for which I see no reason other than inertia/low-priority for translating into Rust (e.g. there would be no particular build-system benefit to Rustifying them because C/C++ compilers are needed for the other things anyway)
[1]: https://github.com/rust-lang/rust/tree/master/src/rt (the 'rt' = runtime name is a holdover from when the runtime was not written in Rust)