C was hardly a performance juggernaut in the 1980's, any junior Assembly coder could easily outperform the outcome of the C compilers.

It was by exploring UB to the extreme those compilers optimizers do nowadays, that such language finally got the fame it has 40 years later.

"Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities."

-- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming

> C was hardly a performance juggernaut in the 1980's, any junior Assembly coder could easily outperform the outcome of the C compilers.

I think that's not especially relevant. The issue is that most other higher level programming languages had poorer performance and/or inserted undesirable mysteriously-timed lags in performance. Fortran had excellent performance, but Fortran at that time couldn't handle many constructs that C can. Some Common Lisp implementations at the time had reasonable performance, but the garbage collectors often inserted pauses (ugh!), and many were expensive at the time too.

Also: The 1980s was the rise of the IBM PC-compatible (and the Macs too). These were machines whose underlying chips matched C decently well (they had hardware-implemented large stacks unlike the 6502), however, these machines were underpowered compared to what some people wanted them to do. This also had a rise in Unix servers, where C was their native tongue.

The 21st century renaissance of high level languages got us somewhat back on track.

I write C because I like C. That's the only reason I've got. It's what I feel comfortable writing code in. I tried learning Rust but I just couldn't get used to it.

I like C where I write the functions and the structures and the compiler just translates it to the simple processor instructions you expect it to. No complicated hidden machinery under the hood, just simple unmangled symbols pointing at simple code that conforms to simple ABIs. This simplicity is also the reason the so called "C ABI" is so ubiquitous.

Another reason I write C is it's one of very few languages with freestanding code support. I only write freestanding C targeting the Linux kernel-userspace ABI. In my opinion C is a much nicer language without the libc and its legacy. I really enjoy it.

> Then why are you writing C? You could be writing some other, higher-level language instead if performance is not your top priority.

This goal seems somewhat oxymoronic - if the "goal" is to be keenly aware of what the compiler will do and double check all assembly, then you shouldnt use C. If the goal is to ignore assembly and not pay attention to these sorts of things, then you shouldnt use C.

The only valid niche I see is where the goal is to use C, not really have to worry about the assembly, have it do the "right" thing on your platform. I.e. no undefined behavior, just underperforming (and called out as such). Then you can go in and "approve" various optimizations.

> Then why are you writing C? You could be writing some other, higher-level language instead if performance is not your top priority.

If performance is your top priority C is also the wrong choice.

What would you suggest instead?

If you are writing general purpose software, I would suggest Rust if I have nothing else to go on, although there are plenty of other good choices if you know more about the problem.

In a few cases there is today a special purpose language for the kind of thing you're writing which will knock both C and Rust on their backs for performance because it was never trying to do anything else.

I think C is still a good choice for the following reasons: - Performance is generally very good and while special languages can sometimes be better it usually easily possible to get the C code to the same level. - But with special languages you will often run into limitations where you are stuck. - It has long term stability - Compile-times are short which I really like - There are good tools - It has very good interoperability with everything - The code an easily be reused from most other languages, so it does not tie you into a specific framework - etc..