C is deprecated and used only on legacy code or

Problems be that it works and any alternatives turn out to be janny tier. Eruocuck tier coders please provide alternative to C, I don't like it but it's better than rust.

>undefined behavior
formal verification
>parallelism
extensions like openmp and ispc
>cache
performance counters

the anti-x86 ramblings spread randomly throughout the text are hilarious, some architecture and some language might be better but no data to show for it. no surprise an opinion piece like this gets published in a low tier journal and doesn't even rack up 5 citations

>formal verification
Exhorbant costs for errors that do not happen in higher level languages.
>extensions
Non-standard, bye.
>counters
Non-standard

Rust, C++.

t. doesn't know how computers REALLLLLLLLLY work cause he doesn't reimplement linked lists every time

Attached: segfaulting cnile.png (627x722, 114K)

Who gives a shit how computers work, seriously. I make software that just functions with correctly chosen data structures and algorithms. Everything else - compiler job.

>it is not a low level language anymore
It has never been one, dumb piece of frog shit

Attached: 1567423511592.jpg (276x280, 42K)

>Exhorbant costs for errors that do not happen in higher level languages.
Higher level languages have exorbitant performance costs.
>Non-standard, bye.
>Non-standard
So what?

>C does not represent in any way what happens inside modern CPUs, memory layouts, sanity checks, segmentation, etc...
Yes, and?
Like any programming language it is an abstraction of the hardware, in this case the abstraction of C is closer to the hardware then many other languages. While it doesn't reflect what is *actually* going on (the most important part you forgot is caching) it represents a part of what is going on.
And some of these parts which C doesn't reflect aren't even controllable by the program itself, eg. internal error checking when accessing memory.

>There is no reason to write C
That is a non-sequitur.

>it is not a low level language anymore.
By that standard nothing but assembly is.

>OP can't npm install a brain
>this post

>performance costs
Not humanly noticeable ones. C++ and Rust have very nice standard libraries and/or standard library reimplementations.
>So what?
So they have no standards to follow.

>closer to the hardware then many other languages
It's not..... that's the point. Not even partially. Please read the article
>assembly
That's true and a good bet.

>Not humanly noticeable ones. C++ and Rust have very nice standard libraries and/or standard library reimplementations.
Not everything is a video game or web browser.

>So they have no standards to follow.
Circular reasoning is circular.

Well people write stock trading machines on C++...

They use FPGAs for that shit now, good luck competing with that.

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said "to piss you off", but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to piss off, so that he doesn't come and screw up any project I'm involved with.

C++ leads to really really bad design choices. You invariably start using the "nice" library features of the language like STL and Boost and other total and utter crap, that may "help" you program, but causes:

- infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)

- inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.

In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap.

So I'm sorry, but for something like git, where efficiency was a primary objective, the "advantages" of C++ is just a huge mistake. The fact that we also piss off people who cannot see that is just a big additional advantage.

>2007
I wonder what's his opinion about C++11 and up.

C TRANNIES BTFO

Well then it doesn't matter what language you use, get an asic.
>horrible language
Stopped reading right there. It's an amazing language because it assumes nothing by default and allows you to make your own zero overhead abstractions, and it all compiles to machine code. The rest is human factor.
>only sane choice
Okay show me a generic hashmap for C with the same lightweight syntax and automatic memory management, that also passes or surpasses all STL specifications of std::unordered_map.
>don't work
STL literally does work.
>inefficient
STL is a collection of extremely optimised algorithms with compile-time wrappers for them. That's it. There is only one way to iterate over an array. There is only one way to add an element to a simple unbalanced BST.
>rewriting
Just add the appropriate template specialisations over STL for your meme class.
>available in C
Lol.
>understand
Yeah at the rate of 50 vulnerabilities a day.
>we
This whole thing was pasta wasn't it.

It's a Torvalds copypasta from 2007

Why would a C developer opine on C++?

>assembly
Modern arm and x86 assembly are not low level languages either. No one except the chip designers have access to low level languages for modern chips.

C programmers have only tried 1970s programming languages but somehow think they have a very educated opinion on everything post-2005.

New hardware always targets C first.

Why?

Because C is simple to implement, both for hardware manufacturers and complier writers.

C is well understood, an industry standard. There is no incentive for engineers to build towards another language.

C is here to stay, sorry OP.

>hardware manufacturers
No, hardware manufacturers need to spend extra resources to keep up this idiotic charade of a linear memory map and zero-cost pointer dereferences.
>understood
Full of UB.
>industry standard
This isn't the housing market or shoe industry, standard = legacy.

Wrong, C is always the first language on the scene because its semantics are synonymous with pure, unadulterated computation. That's what "C" stands for, after all.

>hardware manufacturers need to spend extra resources to keep up this idiotic charade of a linear memory map and zero-cost pointer dereferences

Attached: 1546092287810.jpg (800x450, 45K)

Allowing C++ is not the same as written in C++.
Gcc is still mostly C. There is also more Ada than C++ in Gcc.

GCC is a multi-language compiler. The reason why you see C++, Ada, Go, Fortran, etc in the source is because of the various frontend implementations for each language supported. The Ada frontend (GNAT) for instance is written almost entirely in Ada and that's basically where all the GCC Ada code is. The C frontend is still written in C because you don't need anything more complex than that, and so forth.

GCC's backend is still primarily in C. The only places you'll see C++ are mostly in the other frontends for like Go, etc.

Python is written in C.

GCC is written in Lisp-like C++ and it's never ever going to change.