now we both came here to get a discussion going; now we've got one, you can drop out of the troll personal attack mode.
So you have made quite clear that you find the various named non-bare-metal languages used for 'systems projects' distasteful. But you can't make them undone. You can say they were the wrong tool for the job in your opinion, too, but you can't say that others are wrong to consider them system languages.
An easy and accessible rule of thumb goes as follows:
Could I use this language for:
Writing an OS for a PDP-11 that was reasonably close to the assembler in performance albeit not compactness?
&&
Writing hard real-time constrained avionics software?
&&
Writing HPC software for scientific purposes that takes advantage of strict memory control and vectorized, hardware-specific instructions for maximum throughput?
With varying degrees of expertise and specialty, C, Fortran, Ada, and C++ all qualify.
Try writing even a simple linear algebra algorithm in Java. You won't get anywhere near Fortran or C++. Try as you might. Even relatively sundry CV work is unpleasant outside of the prototype phase on anything but C++/et al.
I'm sorry you felt attacked, but the scope of experience is relevant to the subject. I realize it's very difficult to discuss one's limitations, or have them pointed out by others, without internalizing it and making it a subject of ego.
I generally stick to the high level tier of languages until I am forced to drop down a layer. Experience and pain have stripped me of all hubris that could lead me to believe humans could overcome the fundamental semantic and informational constraints involved in optimizing code that needs to concern itself with the machine-behavior from a higher abstraction layer. I've done more JVM and GC fiddling than I care to recall.
There's a glass ceiling, you won't escape it. Even Paul Graham, the master Common Lisper himself, took advantage of the relatively easy to use FFI faculties in Lisp to drop down to C to optimize hotspots. This was a common pattern when he was doing ViaWeb, I'm told.
It doesn't have to be that way. I am genuinely sorry if you felt attacked or that I was uncivil. I will find other ways to express myself if I run into another similar situation here. That was a failing on my part, please forgive me.
I'm not wont to pontificate to plumbers as to how they should go about plumbing. I say that as someone who's actually redone the plumbing in a residence from top to bottom with my bare hands before. Despite that, I know I'm not a professional plumber and I don't have the experience necessary to say much about it even if I've technically "dabbled".
I don't let a little experience overstep its bounds.
I was pretty familiar with the intracities of real-time called iirc "guaranteed service" back when I worked at Symbian. That was a kernel written in dialect of C++. And I've written camera and video capture software for, among others, Android phones. So fairly general experience, I'd say. Still so much more to learn.
You, on the other hand Chris, keep calling out Rob, me and anyone else who thinks that PDP-11 is not a necessary requirement for the next decade's "system language" ;) What systems projects have you worked on then?
Indeed I used Oberon (both native and windows-hosted) for a few intense months back some summer in the 90s. I still have a fondness, perhaps rose-tinted by time, for Pascal languages.
I particularly remember when someone made an Oberon pcode VM browser plugin as a 'competitor' to the newfangled Java applets. I think it was caled Juice or something.
Interestingly Chrome NaCL is going in the same direction, distributing pcode (well, LLVM IR iirc) and doing final compilation on-target.
So you have made quite clear that you find the various named non-bare-metal languages used for 'systems projects' distasteful. But you can't make them undone. You can say they were the wrong tool for the job in your opinion, too, but you can't say that others are wrong to consider them system languages.