There are environments that do not have a strong distinction between OS and language. While adored by their users, for some reason they are never very popular. Oberon, Smalltalk and the old Lisp Machines come to mind. (Maybe Forth too, though most "Forth OSes" never tried to do multitasking or even file systems.) I suspect there are anti-network effects holding them back. They support one language and one language only. You can't easily bolt them into whatever OS you already use. None of your familiar tools run on them either. Adoption rates are poor with no way to dip your toe into the environment.
What would a "no OS" system that equally supports multiple languages look like?
edit: Multiple languages that have nothing in common. Think about the insane variety of languages you have available on *nix.
We are getting there with the rump kernel (rumpkernel.org). It now runs PHP, Lua, LuaJIT, C, C++. This is very much work in progress and it is not particularly user friendly, but it is improving rapidly. I plant to look at Go soon, which has built in syscall traps, which need replacing with library calls. There are a whole bunch of environment assumptions, like existence of dynamic linkers, build systems and so on that need to be worked around.
OSv is another option, it makes life easier by supporting Linux binaries modified to be dynamic libraries, and runs several languages too, although it was initially mainly targeted at JVM languages.
Using a standalone Forth is more or less a rejection of the utility of an operating system. My years of using a stand alone Forth for day to day computing instilled in me a deep cynicism when it comes to the complexity of operating systems.
I've been reading kragen mailing lists where they bootstrap a lot of 'utilities' on metal with asm (using alt keycodes as 'editor', funky). It's very inspiring and relaxing to see how few things you need to start using a computer. It flatten the whole abstraction stack into a thin core.
> IIRC the Lisp Machines supported C in addition to the system's dialect of Lisp.
IIRC the Lisp Machines (well, CADR at least) compiled code down to some pretty high-level machine code implemented in microcode. How many standard C idioms could actually be expressed in that kind of code?
I'm also not seeing how it would give a speed-up, which is the usual reason to code in C.
No reason you can't compile C down to that. It's just that there will be less of a clear performance advantage for C as some of the semantics will be slightly awkward to map to that instruction set.
You might still get a speedup by writing C in some areas, but I think the real reason for supporting it is that you have a bunch of legacy software and drivers written in C, and it's easier to get a C compiler working on that platform than to port all that software.
I know all these names, unfortunately only by reading and not by experience. Some lispers are also keen on bypassing OS interface and emit binary code on the go.
"An operating system is a collection of things that don't fit into a language. There shouldn't be one." --DanIngalls