Fun fact: C used to be considered a high-level language. Now everyone talks about it being "close to metal" which to olds like me is a dead give-away the person either doesn't know C or doesn't know the "metal". Most of the stuff people think of as being the "metal" in C are, in many cases, virtual abstractions created by the operating system. Embedded development w/o dynamic memory allocation less so... but that's not what most people are talking about.
Well it depends on what side of the kernel/userspace boundary you are talking about doesn't it.
While C for userland programs may need to conform to the operating system's libc and system call interface abstractions, on the other side of the syscall boundary is C code (ie. the kernel) that is indeed very "close to the metal".
Running any code in the CPU's most privileged ring, regardless of language, is going to give you access to directly programming the MMU, scheduling processes across multiple CPU's, control over caches to a fairly large extent, and the ability to control every device in the system. A large amount of this is achieved by bit-banging otherwise inaccessible registers in the CPU itself via assembly (ie. in the case of the MMU, GDT and IDT for x86), or via MMIO for modern busses/devices. The language doesn't necessarily "need" to have a complex model of the entire physical machine to be able to achieve all of those things. How much closer to the metal do you want to be?
You really want your programming language to have innate constructs for directly controlling the baggage the x86 CPU (or any other for that matter) brings with it? I don't.
You also want kernel code to be performant (ie. compiled by a decently optimizing compiler, of which there are many for C), allow you to disable garbage collection or be totally free of it so you can explicitly manage separate pools of memory. C ticks all those boxes which is why its still the most dominant and widespread language for OS kernel development nearly half a century since UNIX was first rewritten in C, and will be for years to come, like it or loathe it, and despite there being much more modern contenders (eg. Rust) which don't have the momentum yet.
All of that is given access by Assembly opcodes, not C specific language features.
And if you going to refer to language extensions to ISO C for writing inline Assembly, or compiler intrinsics, well the first OS written only in high level language with compiler intrinsics was done 10 years before C existed and is still being sold by Unisys.
The only thing that C has going for it are religious embedded devs that won't touch anything else other than C89 (yep not even C99), or FOSS UNIX clones.
And yeah, thanks to those folks, the Linux Kernel Security summit will have plenty of material for future conferences.
Which modern, portable language gives you direct control over the MMU, out of order execution, delay slots and explicit cache access, other than hardware specific assembler? None that I know of can do this in a hardware agnostic way. Do tell.
I clearly mentioned that assembler was required for much of this, where components aren't programmed by MMIO. This would be the same regardless of whether you used Rust, Go, or FORTRAN77 to write your kernel.
I'm not even going to bother with your security comments, we all agree by now. There are plenty of people using C99 in embedded at least in userspace, even the Linux kernel uses some C99 extensions (eg. --std=gnu89 with gcc), and those FOSS UNIX clones have taken over the planet at this point in terms of smartphone adoption, data center servers etc. Despite the obvious flaws, this is still a better world to live in than Microsoft's proposed monoculture of the 1990's.
None, including C, which makes it nothing special. Any compiled language can call into Assembly.
The phones I know as having taken over the world run on C++, Objective-C, Swift, Java, with very little C still left around, and with its area being reduced with each OS release.
As for data centers, there is a certain irony that on Azure those FOSS run on top of Hyper-V, written in C++, on Google Cloud run on top of gVisor written in Go, on Amazon on top of Firecracker written in Rust, and on ChromeOS containers written in a mix of Go/Rust.
Hyper-V runs as a Windows Server role. Windows kernel is C, and assembly
gVisor runs on Linux -> C, assembly
Firecracker runs on KVM, which runs on Linux -> C, assembly
In every single thing you have listed, the closest thing to the "bare metal" is C, and assembly. THAT's what makes C special. Its level of adoption, ubiquity and accessibility. Not its spectacular lack of security risks.
Anyway, you have come a very long way from where the parent poster started which was:
Most of the stuff people think of as being the "metal" in
C are, in many cases, virtual abstractions created by the
operating system.
To which I merely pointed out, on the other side of the interface layer is, most commonly C. And assembly.
Operating Systems design has to and is obviously evolving away from this. I disagree that we have reached "peak C" and that is going to decline before it gets bigger.
Unfortunately pjmlp many of the conversations we have start this way, and devolve into this. I don't think I'm going to bother again. I think one (or both) of us will just have to agree to disagree. Have a nice day.
> None, including C, which makes it nothing special. Any compiled language can call into Assembly.
I wish you joy and entertainment interfacing your managed data structures with assembly code.
Yesterday I was forced to look into COM for the first time. There was some kind of callback that I was interested in, and it had basically two arrays as arguments, only in a super abstract from. I'm not lying, it was 30 lines of code before the function could actually access the elements in the arrays (with special "safe" function calls to get/set data).
Of course, that stupid callback had to be wrapped as a method in a class, and had to be statically declared as a callback with a special macro that does member pointer hackery, and that has to be wrapped in some more BEGIN_MAP/END_MAP (or so) macros. Oh yeah, and don't forget to list these declarations in the right order.
Thanks, but that's not why I wanted to become a programmer.
Not that I want to vehemently disagree with your security statements, but I think I'd love to have a little bit more "show" and less "tell". That also applies to showing practicality of managed languages, practicality of 90's business software development (C++/COM), practicality of dead commercial languages (Delphi + VCL).
Giving just endless lists of ancient buzzwords doesn't help.
> It is coming for sure, I have not forgoten about it, I just have a private life to take care of, you know?
I was thinking you'd look at it before writing your next 25 comments, but it seems I was wrong. So I'll just wait, it's fine.
> The 21st century React Native for Windows is written on top of COM/C++
From a skim I could find exactly zero mentions of COM/C++ stuff in there. Sure, this RN might sit on a pile of stuff that has COM buried underneath. That doesn't mean that COM is a necessity to do this React stuff, and not even that it's a good design from a developer's perspective.
You give zero ideas what's a good idea about COM. Just buzzwords and links to stuff and more stuff, with no relation obvious to me.
If you actually have to go through the whole COM boilerplate and the abominations to build a project with COM, just to connect to a service, because some people thought it wasn't necessary to provide a simple API (connect()/disconnect()/read_next_event()) then the whole thing isn't so funny anymore.
Maybe I was unclear, but it was a C++ program (dealing with macros, as I said - VARIANTS and DISP_IDs and PROPERTIES and stuff). No joy to use.
As for other languages, I haven't touched COM at all but the idea of making GUIDs for stuff and registering components in the operating system doesn't seem a good default approach to me. Pretty sure it's more reliable to link object files together by default, so you can control and change what you get without the bureaucracy of versioning, etc.
> ReactNative for Windows uses WinUI and XAML Islands, which is UWP, aka COM.
Is the fact that COM is buried under this pile more than an unfortunate implementation detail?
