Re: Confusing a language with an architecture
"But no, the architecture is not the point here. The point is that IPC, library calls, and system calls all inherit the insecurities of C, even where no actual C code is involved in either side, because the C conventions are the de facto standard that all programming languages adhere to for interoperability. This is how an Ada process reads an error text from another Ada process as an interger and Ariane 5 explodes, because C inhereted type unsafety from BCPL."
You just made my point... -Architecture- IS IPC, library and system calls and all that nasty talking back an forth stuff, and device driver interfaces, and shared memory, and ... Like DBUS on a desktop is architecture not language.
The article implies C is somehow awful because someone based a poorly defined architecture with it, to the point that when the underlying hardware became more robust the architectural definitions became perverted. The fact that nobody has redesigned the underlying architecture to allow for a more robust and well defined "MI" layer to handle all this is not a problem with the C language, it's a problem with not designing a robust extensible architecture to compile your programs against.
Again, IBM solved this "Interface Definition" problem in the 80's so that their systems could become 100% CPU/hardware agnostic. It seems Apple has defined their systems architecture well enough to change CPU architectures 4 times over their lifetime. Moving from big to little endian is decidedly non-trivial. The Wintel world was a free for all based on the original IBM PC and intel based chips. The fact that nobody deigned to design a proper "MI" layer for commodity PC hardware has nothing to do with 'C' as a language.
"Rust and Swift cannot simply speak their native and comfortable tongues – they must instead wrap themselves in a grotesque simulacra of C's skin and make their flesh undulate in the same ways it does." ®
Paints an interesting picture. Create an MI layer, write the horizontal and vertical microcode, likely lot's of assembler. Make it extensible, define everything you can think of, ... memory map all your IO and IPC. The write your OS against the MI without 'undulating' in a 'grotesque simulacra' of any kind. It's been done before, I've been mildly surprised some university never made a project out of it.
Whenever I read stupid sh*t like the above statement it makes me want to puke. You want to do IPC differently from 'C' with the latest language of the hour, shut the f*ck up and write it, and nail the API down. The bottom line on all this boils down to assembly language on your cpu of choice.