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.

How do you use ANSI C on bare hardware without help from Assembly (thus a mini-runtime) or language extensions?

For the purposes of interrupt handling, IO ports (not all systems have memory mapped IO) and register access.

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.

Where did I mentioned anything like this?

> Rust, if I remember right, requires restricting yourself in order to do things like kernel writing.

Nope, you just lose the standard library, and have to implement a few language intrinsics yourself.

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.

There's several kernel projects already, you'd have a small community to talk to :) #rust-osdev on Mozilla's IRC is where they hang out.

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).

--freestanding