Secondly, unless you are doing classical VM deployments, the only thing we care about are type 1 hypervisors.
If the language runtimes are running directly on top of a type-1 hypervisor, some kind of container, or bare metal, it is mostly irrelevant for most languages, with exception of C and C++ with their direct dependency on POSIX related APIs.
Taken to the extreme, on serveless workloads, you can even upload the code, and it get magically transformed into a deployment, mostly using managed languages that are OS agnostic.
At the end of the day, if those type-1 hypervisors are self-contained, or need a guest OS as management node, is completly transparent to the managed runtime workloads.
> with exception of C and C++ with their direct dependency on POSIX related APIs
...why would POSIX be special if the POSIX layer is statically linked with the application and would just be a translation layer to anything that lies below? Same way MUSL works on Linux as alternative C library which bypasses glibc and instead directly uses syscalls to talk to Linux.
(also technically the POSIX standard doesn't have anything do to with the C and C++ standards)
The POSIX standard definitely has something to do with C standards:
> Parts of the ISO/IEC 9899:1999 standard (hereinafter referred to as the ISO C standard) are referenced to describe requirements also mandated by this volume of POSIX.1-2017. Some functions and headers included within this volume of POSIX.1-2017 have a version in the ISO C standard; in this case CX markings are added as appropriate to show where the ISO C standard has been extended (see Codes). Any conflict between this volume of POSIX.1-2017 and the ISO C standard is unintentional.
Well ok, the two standards are overlapping where it makes sense, I stand corrected there.
But nothing prevents me from writing C or C++ programs on Windows which don't have a single POSIX (or even libc call) in them, but exclusively use Windows system DLL calls - and those are still entirely valid C or C++ programs (although I'm aware that the situation is muddy for some libc calls which some compilers treat like builtins, e.g. memset and memcpy).
https://techcommunity.microsoft.com/t5/windows-os-platform-b...
Secondly, unless you are doing classical VM deployments, the only thing we care about are type 1 hypervisors.
If the language runtimes are running directly on top of a type-1 hypervisor, some kind of container, or bare metal, it is mostly irrelevant for most languages, with exception of C and C++ with their direct dependency on POSIX related APIs.
Taken to the extreme, on serveless workloads, you can even upload the code, and it get magically transformed into a deployment, mostly using managed languages that are OS agnostic.
At the end of the day, if those type-1 hypervisors are self-contained, or need a guest OS as management node, is completly transparent to the managed runtime workloads.