It's fine as long as the runtimes themselves are tiny and low-overhead. Most C and C++ programs carry around a mandatory "runtime", usually denoted by the module name "crt0". It's basically just a translation layer between the OS's executable calling conventions and main()/return that weighs a few dozen bytes and only runs during startup and exit of the app to do things like set up argc/argv/envp and put the exit code where the OS expects it. The C and C++ standard libraries provide many of the services that a framework runtime would otherwise provide, but they're usually much smaller than a modern "framework" and provided as part of the OS. Modern Windows desktop apps are supposed to install their own copies of the DLLs (msvcrXX.dll/msvcpXX.dll and friends). You can link against the "known DLL" msvcrt.dll, but I don't think linking to it is officially supported for any non-ancient version of Visual C++, and IIRC it has a bunch of carefully preserved bugs for backward compatibility. Maybe there should be something like musl for Windows?
> I'd actually like to see an interface for micro controller style apps. Like An 8 bit AVR emulator that could do some kernel syscalls to the hosted environment. It would allow for a class of apps to be written that would have a fixed memory footprint. There's some Irony here in that this would also be a runtime.
As rebootthesystem suggests, this sounds a lot like a niche that would be well-served by a purpose-built Forth interpreter. Such interpreters have been used to e.g. facilitate interactive development or hot-patching on actual microcontrollers and other constrained systems. There's a surprising amount of symmetry with Lisp systems, but the traditions of Forth tend to value small code for both application and implementation. There's probably nothing preventing a tiny Lisp from filling the same role.
> I'd actually like to see an interface for micro controller style apps. Like An 8 bit AVR emulator that could do some kernel syscalls to the hosted environment. It would allow for a class of apps to be written that would have a fixed memory footprint. There's some Irony here in that this would also be a runtime.
As rebootthesystem suggests, this sounds a lot like a niche that would be well-served by a purpose-built Forth interpreter. Such interpreters have been used to e.g. facilitate interactive development or hot-patching on actual microcontrollers and other constrained systems. There's a surprising amount of symmetry with Lisp systems, but the traditions of Forth tend to value small code for both application and implementation. There's probably nothing preventing a tiny Lisp from filling the same role.