Well, sort of... but what language isn't that true of? And really, what language isn't that more true of than C?
And adding inline assembler to manage the hardware - caching, that sort of thing - is just how it's done. Maybe it's possible to make a library ( or a bunch of #defines ) that manages this for you?
I really am sorry you have to use it, but there are rather large populations of people who go completely untroubled with it.
The current ones might be like C on that part, might do something different. I haven't evaluated that. Here's a few:
http://www.astrobe.com/Oberon.htm
SFAIK, ( meaning I don't really ) the various "Mikro" probably do the same thing that the native toolsets for , say PIC, do and simply add default, built-in symbols for bits in control registers and things like turning interrupts off/on. That keeps the amount of assembly further down.
I feel confident in saying that because they'd want to make defection from the default say, AVR compiler chain as painless as possible.
And of course, Linux drivers/ioctl() help a lot with bringing kernel mode things into user space. Using assembler in a driver is just one of those things we find acceptance with.
"large populations of people who go completely untroubled with it."
Stockholm syndrome.... Or a lack of imagination about how things could be better. There really is a cult-like adoration of C - I think mostly by people that don't use it and learning it in college and long for something as simple
I've used it for 30+ years. It's not the only thing I've used. But I've used it a lot, for deployed systems that Just Work(ed)(tm). They don't have a lot of UI, usually.
You don't get "cross-platform assembly" in a complete 100% sense and get the enjoy the fruits of hardware diversity. An escape to inline assembly is PERFECTLY FINE.
The Linux kernel doesn't use that much assembly. But yeah - "just write inline assembly" is exactly how it's done. And as someone who's done a few Board Support Packages for Linux and other O/S-es, it's not a huge risk - there's generally a port for a processor, so a small number of people write the inline assembly and it gets distributed widely.
I don't think people who don't like 'C' should use 'C'. I don't like Java too much, so I pretty much refuse to work in it. I don't touch Web stuff at all, beyond a few weeks here and there.
You have to use a pretty weird process to write robust and reliable systems in 'C' but it's not exactly difficult. It just takes... six months of knuckle busting most people don't have. Maybe three months. You have to smooth over learning some arcane rules.
I think that the emphasis we see online on 'C' comes from open source, in particular the Linux kernel, and it causes this weird ...status rift to open and people fall into it.
I'd been programming professionally for twelve or so years prior to even seeing Linux. In 'C', Pascal for a couple years before 'C'. I FIRMLY believe that 'C' is the mechanism to get the most reliable and deterministic solution to problems. Note I didn't say "fastest". But that's when I do it; after the last few years, there's enough whining about how bad 'C' is that I kinds shrug and say "hey, if it hurts you're doing it wrong. Make yourself happy."
but I'm on teams with people who use all the fancy high level stuff and ... frankly, it's not my stuff that doesn't work. Because I've done this for 30+ years.
What language has all of these covered? (Rust?)
None that I know of from the last 20 years or so.
> inlining
This one is tricky. Sure, GCC ignoring the inline keyword is annoying, but sometimes figuring out if something is inline-able is undecidable, and sometimes things just aren't capable of being inlined.
> blocking inlining
This is something that I don't understand why we don't have. Sure, lots of times you would rather inline than not, but sometimes inlining the wrong expression can subtly change the performance / lookup / dispatch semantics in weird ways. I've no hard examples of this, but it should be easy enough for almost every language to have a --no-inline flag.
> RVO
C++11 and up somewhat handle this with move semantics. Having a separation of rvalues / lvalues certainly helps, but the distinction could probably be clearer, as it can get to be a gruesome and hairy topic depending on your types.
> const != immutability
That you can often just "cast the const away" is really the problem here. I think Rust improves on this space as there is no safe cast to remove const-ness, but if you ever find yourself or somebody else casting away const, you / they should realize that they are going against the design of the system. I'm still undecided if "mutable" keyword in C++ classes is so horrible in this context, as it certainly helps in making const-types usable with the rest of the language (which is inherently non-const).
It would be fair to ask whether that intent was a good idea. It would also be fair to point out that many (most) times people cast away const-ness simply out of expediency, rather than using it the way it was intended.
C is a terrible cross platform assembly b/c it doesn't allow you the level of control which one would expect in this day and age. Maybe it was written in the days when CPUs were brain-dead simple, but basic things that are available on most architectures aren't part of the language. It has no notion of a CPU cache, it has no notion of branching (you can't tag a likely branch and an unlikely one), it even goes as far as to ignore user keywords for inlining and provides no keyword for blocking inlining. RVO is implicit magic that you just pray happens. Const != immutability.
When you write C you have no notion of what the compiler is going to output whatsoever
A lot of these things are available through compiler extensions (so great, now it's not cross-platform), but even still the language is broken. "Expert C Programming" has a really long chapter that goes over all the more confusing subtly problems C has beyond just arrays being pointers-but-not-really.
I have to use C pretty regularly and all I can think is "God.. why hasn't anyone made this better yet"