I don't know, I work in the games industry and we're currently building a small project that's probably 95% C(the only C++ we have is for one library that has to have a C++ wrapper). It's just.....we don't need the C++ features, the compilation times are instant(last project I worked on was a large AAA game in C++ and compiling it from scratch was about 40-50 minutes on a single workstation), and pretty much all libs are C anyway. I'm not going to make the performance argument since it's mostly irrelevant nowadays, but I just don't see us using C as anything out of ordinary.

Y'all should try D! D compiles really fast-- the D reference compiler can compile itself, the standard library, and the codegen backend in less than 5 seconds, on a single laptop core. It uses a streaming architecture to achieve this. It runs fast because it is supported by both GCC and LLVM. One of its guiding principles is the thing that looks like C works like C-- all members of a file public by default, for example.

Some experimental compiler builds (Calypso) can compile D for use with C++ libraries as complex as Qt.

You can start porting your D project to C by using DPP- it allows you to #include C headers within D- and use macros. Putting "extern(C):" at the top of your file let's you interoperate between C and D.

Andrei Alexandrescu wrote Modern C++ Design, and is the co-captain of D. The captain of D created the first end-to-end C++ compiler.

Long compile times are almost always because of bad use of header files which include basically everything, insteda of only the used component. And this sometimes is because of bad separation of concersn / modularization.

I used to agree with this, but having spent a while in a very good C++ project (by C++ standards), even if we try to always forward declare and not include any unnecessary headers in headers, we still have a clean debug build time of 30-40 minutes. Even changing a single line in a cpp file, will still take around 30-40 seconds at best with incremental builds. I think long compile times are in the eye of the beholder, but often it feels like people have just gotten used to unnecessarily long compile times because they've forgotten how fast computers are and how fast a compiler should be for most of the work except for maybe some of the more complex optimizations in -O3. It kills productivity, and should really be a much larger focus than it sometimes seems to be.

Well said, I could not have said it better. Just to add, the productivity boost you get from short build times, in a long run, think of a project you work on for years, will out perform ANY gain you get from using a library, templates, and the like that kills your build time.

We use Delphi at work, just did a full rebuild of our core product, 978015 LOC compiled and linked in 22 seconds on my aging i7 4790k.

If it’s just a single line at a leaf in the deptree, it should only be taking time to link everything together.

Still, long compile cycles are my kryptonite... 0 productivity. Horrible. Back when I was doing java, I patched hibernate to serialize and deserialize the generated code, so startuptimes would be lowered with about 80%.

My setup back then used hot code replacement, but so many people would just simply wait 1-3minutes for every single change...

As soon as you include C++ stdlib headers (even only for the stdlib features you're actually using), you have tens- to hundreds-of-thousands of lines of complex template code in front of your own code, and this in each compilation unit. In the end your own code is maybe one percent of all the code the C++ compiler needs to work through each time something is compiled (depending on how many source files you have, this is also why unity builds - merging all source files into one - are so much faster in C++).

In comparison, CRT headers (when compiled as C, not as C++, as in that case additional C++ bloat is added) are usually a few dozen to a few hundred lines of simple declaration code. Compared to C++, it's very hard to make a C project compile slowly.

"Bad use of header files" is the fault of C++, not the developers. Until Stroustrup fixes the header processing behavior (it's 2019 already...) C++ will not become a sane language to use for new development.

> Until Stroustrup fixes the header processing behavior (it's 2019 already...) C++ will not become a sane language to use for new development.

C++ does not have a BDFL like other languages, C++ evolution is governed by a committee. In other words, Stroustrup himself needs to submit any changes he wants to the committee and there is a vote ...

C++20 modules should partially solve the header processing problem, but it will take years until it will become widespread in big companies.

I'm yet to see a C++ project that compiles as fast as a C one.

About a decade ago I used a Zipit Z2 as my primary machine, as a fun experiment. It had 32 megabytes of RAM. Back then, that meant you could just about run Debian (who needs X11 anyway). Believe it or not, I often compiled software on this thing, and I quickly noticed that projects written in C would generally compile, while C++ builds would invariably choke from memory exhaustion. This was actually the first time I became aware of any difference between the two.

A very educational experience!

groff does, but it restricts itself to C headers only.

It's very confusing, they start off saying C++ is too complicated and then go basically reinventing C++ with (IMO) absolutely awful syntax.

I think they're missing the point of why people use C - there's no magic. It's pretty much the wysiwyg of high level -> asm. If you want a systems language with magic there's C++. If you want a safe one there's Rust.

Personally if I were going to make C better, I'd add a better macro/template feature so you don't have to write generic code as a define block with slashes all over, something like Go's defer, and some low level stack unwinding support. Maybe tuples as struts with numbered fields, but no magic syntax sugar. And that's it. No crazy operators, type theory things, or anything that doesn't do exactly what the code says. Because then it's not C.

But what do I know?

> C - there's no magic

Strict aliasing and weak typing say hello.

> wysiwyg of high level -> asm

Except neither GCC nor Clang compile even remotely predictable ASM. It's easier to predict OCaml assembly output than the GCC's one.

How is strict aliasing magic? How could you possibly define the meaning of accessing an object through an incompatible type since the type of an object determines how the compiler interprets its value? The bits stored in the object do not even necessarily correspond to a value for every type, after all. And that's not even considering the fact that there is a great deal of freedom wrt how implementations can represent floating point numbers, etc. so how can the standard impose a requirement on what happens when you, say, access a double as an int?

What do you mean by weak typing? That can you cast away basically anything?

>It's easier to predict OCaml assembly output than the GCC's one

Surely you are kidding. If that were true, why doesn't OCaml curb-stomp C in benchmarks? IMO GCC's output isn't even a little surprising, esp. once you've gained experience with its favorite optimizations.

Not only can you cast away anything, but:

- casting away types unsafely is required for many common patterns in C, including any form of runtime polymorphism

- basically anything involving numerics has a good chance of happily casting for you without asking you or telling you

>- casting away types unsafely is required for many common patterns in C, including any form of runtime polymorphism

Which patterns? I'm thinking of stuff like the Berkeley Sockets API, which you can absolutely implement safely.

re numerics: fortunately, that's 100% amenable to static analysis (see -Wconversion, -Wsign-conversion in gcc/clang and coverity's warnings about potentially unsafe casts - e.g. promoting an int to a long is always safe, but an int to a float not necessarily) and follows very straightforward rules.

> Surely you are kidding. If that were true, why doesn't OCaml curb-stomp C in benchmarks?

Exactly because nobody (except backend writers) can predict what C compiler backends emit, especially when abusing undefined behaviour.

OCaml: https://godbolt.org/z/8bWDXy C: https://godbolt.org/z/WAjsvk

I've never actually looked at the output of an OCaml compiler, I have to say I'm surprised by how clean it is. But I wouldn't call it more predictable than that C's output.

>C

You forgot about -O2/3.

> Surely you are kidding. If that were true, why doesn't OCaml curb-stomp C in benchmarks?

You are confusing predictability with performance. OCaml is way more predictable exactly because it generates way more straightforward code.

On the other hand, GCC could do all kind of stuff, generating any sort of assembly. It can even rewrite fairly complex math functions, simplifying them.

Parent was talking about predictable ASM, not about performant ASM.

I don't think optimizations count as magic. It'd be entirely unreasonable for a language to not do them and they don't change the meaning of the program, undefined behavior aside.

"No magic" is meant as shorthand for "the minimal amount of magic we can reasonably expect given the history of the language and requirements for backward compatibility, and the least magic of any high level language with more than 3 users." Please don't make me do this again for the number 3.

> don't think optimizations count as magic

It's not about magic, you were talking about

> It's pretty much the wysiwyg of high level -> asm

which is not true until you use some ancient compiler from bell labs era. Modern C compilers emit totally unpredictable asm.

>It's pretty much the wysiwyg of high level -> asm.

Everyone with this opinion needs to read this[0].

[0] https://queue.acm.org/detail.cfm?id=3212479

I remember seeing people from INRIA talking about CompCert (a formally verified C compiler http://compcert.inria.fr) and the main idea was that C was still the main language used in some critical application like aviation and military equipment.

This is why it was not rare to see defense company or Airbus financing those research.

> In the age of Go and Rust, which already have a hard time finding niches

To make the time even harder, in that niche space, you already have decent enough languages like Nim and Zig etc.

So yeah, the market is really pretty saturated, I don't even have time and project idea to try them all, let alone bring them to work.