At least, that's how I've usually understood it. And the example you mention seems like a complaint with C++20's Ranges in particular. I guess I'd fall into the, "but can't you just ignore the parts you don't like?" camp.

This post is written in the context of game engines, but I see a lot of the same 'OG C' arguments made when people in embedded development resist giving C++ a try.

We're all writing resource-constrained applications that work on tight time budgets, and none of us feel comfortable throwing up our hands and 'trusting the compiler' in that sort of atmosphere. But C isn't getting any younger, and it's hard to do polymorphism without getting hack-y.

Now, who's turn is it to advocate Rust?

The issue is that many libraries (including std/stl) tend to produce long compile times.

I feel that in modern C++ modern style ”trust the compiler” often means ”leave the programmer out of the loop”

I really, really would hate to have to try to debug the ranges example, for example.

  use std::time::SystemTime;

  fn main() -> Result<(), Box<dyn std::error::Error>> {
      let t0 = SystemTime::now();

      let triples = (1..).flat_map(|z|
          (1..=z).flat_map(move |x| 
              (x..=z).filter_map(move |y|
                  if x * x + y * y == z * z {
                      Some((x, y, z))
                  } else {
                      None
                  }
              )
          )
      );
    
      for triple in triples.take(100) {
          println!("{:?}", triple);
      }
    
      let elapsed = t0.elapsed()?;
    
      println!(
          "{}", 
          elapsed.as_secs() as f64 + elapsed.subsec_nanos() as f64 * 1e-9
      );
    
      Ok(())
  }

In debug mode, it runs in 0.047586s, in release mode, 0.002304.

I was pleasantly surprised to see this is actually better on the build times and debug build performance, given that those are two often cited sore points in Rust.

I would also say that while this is a little bit noisy, it is more readable than the proposed C++20 version. "1.." looks more like a range starting at 1 than "iota(1)" does. There's an actual "if" statement in there.

In fact, while Rust doesn't officially have generator/coroutine support yet, it is available in nightly builds for the implementation of async/await. If you use the nightly compiler, enable the unstable features, and wrap an adapter type around Generator that implements Iterator, you can write:

    let triples = IterGen(||
        for z in 1.. {
            for x in 1..=z {
                for y in x..=z {
                    if x*x + y*y == z*z {
                        yield (x, y, z)
                    }
                }
            }
        }
    );

Rust doesn't have generators yet, so this is only really fair to compare to the generator/co_yield example in C++ (which is also proposed but not yet standardized). I'd say Rust's syntax compares favorably to that example; the ranges are more clear than the traditional C-style "for" loops, there's native tuple syntax, and it's just be "yield" instead of "co_yield".

While on C++ I can take advantage of incremental compilation and linking, while using binary libraries for all dependencies, with cargo I have always to build the whole world from scratch minus standard library.

It still doesn't do incremental linking, and cargo still builds everything from scratch without any support for binary libraries.

Additionally, it is not like every C++ library is full of meta-programming templates.

Finally, there are other languages with library "metadata" and generic data types, which can easily beat Rust compile times like Delphi, Eiffel and Ada.

And are you sure GCC's Ada has better compile times? My sense is that so few people use Ada at scale that we don't really know.

Rust is definitely further along the scale towards the end of "giving more to the compiler so it takes longer". I usually like the trade. Most of the time.

While I do appreciate build speed improvements, saying that it's better than it was isn't a super high bar in terms of user experience.

I love Rust, I really do, but it's still incredibly slow. I'm excited for any progress it makes on this front.

> In many ways the '++' in 'C++' comes from giving the compiler more information to work with.

This is definitely not the origin of the '++'. I believe the '++' name was literally a play about "one better than C."

Borland still did a great job with their implementation performance-wise, and the legendary reputation of their Pascal compilers is well-deserved. But they had a solid foundation to build on in form of a tool-friendly language, which C++ just doesn't offer.

Same applies to C++ Builder, at least until they decided to move to clang.

Also, IIRC Delphi had only recently gotten generics, and they're still not heavily used? I suspect that code that's heavy on those will compile pretty slow.

Compilation takes 0.064 seconds, produces 8480 byte executable

I am experienced with Asm so I can come up with an instinctive order-of-magnitude estimate, but even those who aren't should try to roughly estimate how many machine instructions are required to implement that code, and come to the conclusion that over 8000 bytes for three nested loops with not much in them, a comparison, some arithmetic, and a handful of library function calls seems rather excessive. Even 800 would be on the high side --- somewhere around 100-200 bytes is my estimate.

Also, watch this 4k demo (everything you see and hear is generated in realtime by a 4096-byte executable):

https://www.youtube.com/watch?v=jB0vBmiTr6o

otool tells me the assembly routine is 74 instructions (279 bytes, if I’m counting correctly)

I wouldn't call it fluff: even assuming no debugging info (which you won't have in your avr object file) it has info needed at runtime (program start time) such as where to load what into memory, how much initial uninitialised memory to allocate when starting up, etc. It all gets used.

If I dig into the .text segment of the optimized executable, only 235 bytes belong to the main function (others are stuff like __libc_csu_init and register_tm_clones). Looking at the assembly the loop would be about 123 bytes.

So lots of overhead, but I wouldn't say it is in the nested loop.

You have to be careful, a lot of those 8000 bytes might well be printf().

If it was a statically linked executable, it would be far bigger than 8K.

https://linux.die.net/man/1/size

Haskell, Rust, Scala etc. also have a lot of trouble with compile times. I wonder why, though - is it just a matter of priorities being placed on things other than optimizing the compiler, or is there some actual, inherent complexity in compiling these "modern" languages that doesn't apply to C or Go? (I suspect mostly the former, FWIW).

It’s a complex set of issues that we’re constantly working on.

(So yes, Go and C do not have generics, and so do not have this problem.)

Would it make sense to have two types of generic implementation with a boxing unboxing mechanism. AKA a fast one that requires a rebuild when you monkey with something. And a slow one that doesn't but compiles fast.

I think it'd be acceptable if the 'dev' version used GC as long as the final build didn't. Basically anyway to get the development cycle to go fast.

    fn<T: MyTrait> compile_time(thing: &T) {}
    fn run_time(thing: &dyn MyTrait) {}

It would be possible to find cases where compile time polymorphism is replaced with runtime polymorphism, but I'm not sure it would really gain much given the restrictions.

Now if you start changing the language semantics a lot more becomes possible, but I don't even know what changes you would have to make to the language to let that happen.

1. Maybe monomorphisation overduplicates code, so that different invocations produce the same machine code in the end?

2. If that's not happening, maybe idiomatic Rust code causes a lot of code to be generated where a C programmer would have written something differently, e.g. using a void* instead of passing by value?

3. If that's not happening either, maybe monomorphisation is more or less producing what a C programmer would have monomorphised manually, but it takes the compiler a long time to optimise away abstractions?

It seems that in this C++ example the problem is #3: it takes a long time to optimise away the range & lambda abstraction.

If so, is Rust worse than C++ when it comes to compile times of those? Heavily templated C++ code is known to be slow to compile due to this. Is it much worse in Rust? Are you aware whether C++ compilers do some special optimizations that Rust compiler doesn't have yet?

I don't see what can be done to make this better, the whole point of templates is to "pay" at compile time for some gains at runtime. (or in this case for gains in the amount of code a developer has to write)

There’s at least one thing that could be done, in Rust at least. But it’s only in some limited circumstances. See here: http://www.suspectsemantics.com/blog/2016/12/03/monomorphiza...

  pub fn big_function<T: Into<i32>>(x: T) {
      let y: i32 = x.into();
      ... code that uses y but not x ....
  }

That detection can happen as a side effect of specialising that code to some particular {T: Into<i32>, x: T, y: i32} for the first time. As you specialise that code you record which parts of the type environment actually got used, and you use only those parts as a key in the cache. The type environment object itself could take care of recording what the compiler looked up in it. Another advantage of doing it this way, rather than analysing the code ahead of time, is that it can handle cases where a particular type variable does or doesn't get used depending on what type some other type variable is instantiated to. You could also use the same system to avoid duplicating code that only relies on particular aspects of a type. For instance, a function that permutes the values in a &mut[T] might only care about the size of T and not about the precise type T, so that all its specialisations to T of 4 byte size can call into the same code.

Another thing you'd probably want to do is integrate a basic form of constant propagation & dead code elimination during monomorphisation, so that you don't spend a lot of time monomorphising code that ends up dead for particular type instantiations.

Yes, that's what I'm saying.

> Another thing you'd probably want to do

This is a very interesting idea!

This is partly why there are hacks like unity builds (not related to the engine, where all source is bundled into a single translation unit). These have plenty of drawbacks too so it's not a clear win.

Adding to all of this, there are fancier mechanisms for template meta-programming like SFINAE rules + computed template values. Sure, it's "turing complete" but this is why we see such clever libraries with huge explosions in code generation size. I'm far from an expert in modern C++ features but it's clear that there is an entire interpreted programming language of templates bolted on the to the rest of C++. It reminds me of this post on a similar take on Haskell type level programming: https://aphyr.com/posts/342-typing-the-technical-interview (or similar feats by Oleg Kiselyov).

Monomorphization seems to be the source of 2 major problems: compile time, and binary size.

An optimization that could reduce the compile time by caching the generated code (at least when compiling over-and-over the same code base. i.e. "Incremental compilation") - and it seems that Rust already is doing something with it [1]. I wonder if something specific is done for template instantiations there.

Optimizations aimed at reducing binary size seems much more tricky, if not impossible, except as you pointed out in the limited cases described above. In the regular cases, templates are kind of working as intended: the developer has to think if he/she would have written the same amount of code N times if templates were non existent.

[1] https://blog.rust-lang.org/2016/09/08/incremental.html

Whereas in Go, say, stuff like ranges and maps is just built in, no more abstraction than is necessary to do a generalist job with a few specialised common cases. Even the standard library is largely one-level, direct code, and only abstract at the interfaces.

So simply and literally, C++ has to compile more lines of code to do the thing.

C was unusual that so much of it was in its libraries rather than being built in. Programming language design in those days didn't have the clean differentiation we have today.. or perhaps did: it's fascinating to see the arc bend back.

Pascal and C were definitely influenced by Simula, a language ahead of its time.

When K&R wrote that line I suspect they were thinking more of PL/1 which was the Multics implementation language. Though it has OPEN/CLOSE etc they were keywords not external labels.

I think it’s pretty likely K had heard of Pascal at the time.

More interestingly BCPL’s i/o was via library rather than innate. And c descends directly from BCPL (->b->c) rather than from PL/1; simula-67 and BCPL were developed contemporaneously in Europe.

Again, apologies for my prior brevity.

Edit: especially if that 3 s pays for generating code that nobody has to write correctly or ever look at.

In C++, when compiling:

   for (; *it; ++it) { }

On Haskell's case it depends on which compiler backend you are actually using.

So yes, it is a matter of effort spent in the code compilation, specially if the language does support modules.

Today I'm trying to port some big old Embarcadero (Borland) C++ projects to their new clang-compiler but the compile times are so terrible that I'm not sure this will be usable at all (and these projects are mostly C++98).

I've also played a lot with Borland C++ Builder and the compile times for C++ (pre-C++98) are comparable (that is, practically instant).

Well, as explained in the article, those 5 lines generate hundred thousands of lines of code behind the scene.

And you don't use C++ for fun, you use it because you have a serious performance problem. And in that case you'll wait the compile times, because there is no alternative.

Let's not even go into link time code generation or profile guided optimizations, which increase compilation times by another order of magnitude.

That's part of the problem; most of the time, the "thousands of lines of code" that are created from type-generic code have a lot of useless duplication, and the compiler has trouble coalescing the duplicated and redundant code (I don't even think a serious attempt is made, AIUI). There's a lot of scope for improvement.

And "modern" compile times... increasing the time between results and further thinking and writing. Don't forget that; the article doesn't.

And "modern" debugging... well, good luck.

It is all a matter of focus and pratice.

Writing a composition score for an orchestra falls under similar conditions, how each instrument sounds, how they sound together, when each comes and goes into play, and so forth.

Most complaints about C++'s complexity can be equally applied to languages that look deceivably simple like Python.

Complexity is like thermodynamics, it gets pushed somewhere, if it isn't on the code, it gets shoved either into boilerplate, or architecture.

Sure, Python makes it easy to listen on a socket, parse HTTP, and send HTML down -- hiding a lot of complexity. But it's made it impossible to do so very efficiently and scale up. Try and dive into Python's stack for that (Re: 'hold in your brain all the "modern" features'), and you'll get lost in a myriad of CPython (or whatever flavor you choose) generics and indirection that you can't optimize. Startup times matter, because you are all about hiding complexities and went "serverless" and constantly eat cold starts (Re: '"modern" compile times').

I think it's apt to compare "modern" C++ as moving towards something like Python. Not great for a lot of applications of C++ (Re: games, in the article and my focus) or its perceived goals as a better C. That's the point. Many of the C++ additions are being slagged for making a worse C. It's looking nothing like C any longer. It's a giant ball of complexity with dozens of ways of doing the same thing and hoping you learned them all.

This is why I think languages like Rust (or even Go) get a lot of attention. They have a good interop story with C, like C++ has. And if we're going to learn a bunch of non-C looking language grammar, C++ is doing a worse job.

The language + standard library + C API references are around 2392 pages, not counting the other minor documentation like the 500 PEPs, release notes and differences across each Python release, even minor ones.

Then there is the whole set of meta-classes, decorators, mixins, generators, operator overloading, multiple inheritance, abstract classes, fp like programming and much more.

The big difference to C++, is that the community doesn't care about performance, leaving the PyPy guys a Quixotic battle regarding adoption, which isn't the case with C++ compilers.

Even C isn't as simple as many think, with its 200+ documentated cases of UB, and the days that C mapped 1:1 to PDP 11 Assembly are long gone.

How C code looks like, and what gets generated via auto-vectorization, GPGPU code, SIMD intrisics are very much two worlds appart.

As for Python performance, on the contrary, I think there was a large portion of the Python community that did care during my years with it. I think 3.x adoption was hurt a lot by being slower than 2.7.x. I think a lot of the community jumped ship to Golang or similar, for both performance and complexity reasons.

I would absolutely love for C++ to tackle C UB or make incompatible insecure C. Instead, we get stuff like Ranges, time and again. I'm struggling to understand what complexities you are finding it covers that are worth supporting forever, committing gray matter, committing productivity loss, committing debug travesties, &c. Say I'm a musician that can hold complete compositions in my head; why should I commit this feature and its baggage to memory?

Because C++ is the sane alternative to C on OS SDKs, HPC, GPGPU programming, regarding portable code.

Now, ideally as memory safe systems advocate, I would like to see more of Swift, .NET Native, D, Go, Rust, Java (AOT), OCaml, ...

However, when using languages not endorsed by vendors, it always means inferior IDE/debugging experience, lacking IDE support, manually writting FFI integration code, tracking down which layer is responsible for certain bugs,..., so switching to something that looks easier turns out to become harder in the long run as the whole stack experience suffers.

There are already signs of OS vendors finally improving a bit the situation, with Apple continuously pushing for Swift, Google restricting what is at all possible to do with NDK, Windows teams focusing on .NET Native in spite of C++/WinRT (nee C++/CX), Rust adoption by all big names.

However we are still at least a decade away of any of those languages enjoying a similar industry position in platform SDKs as C++ enjoys nowadays, after 30 years fighting against C.

So I rather keep that baggage in memory, while doing my best to use modern C++, alongside the other more type safe languages, also part of the respective platform SDKs, than additing additional attrition to my production code toolbox.

I imagine my opinion is not unique.

Yyou are probably using many of those and would not enjoy them being slower.

As Wirth languages fanboy, I belive that if Java 1.0 had AOT compilation from day one, instead of leaving it to commercial third parties, and proper value types, the amount of C and C++'s adoption would have looked much different.

"Modern languages like Java and C# may well be superior to old ones like Fortran, PL/I, and C, but they are far from perfect, and they could be much better. Their manuals of several hundred pages are an unmistakable symptom of their inadequacy. Engineers in industry, however, are rarely free from constraints. They supposedly they must be compatible with the rest of the world, and to deviate from established standards might be fatal."

https://www.inf.ethz.ch/personal/wirth/Miscellaneous/IEEE-An...

"In 1995 Sun Microsystems presented its language Java , fully 6 years after Oberon. It incorporated much of the "philosophy" of Oberon, but, alas, chose the style and syntax of C. Around 2000 Microsoft released its language C# as a strong competitor of Java, and Google followed in 2007 with its language Go, even more strongly following (the 18 years old) Oberon. The crux with these languages, which all became wide-spread due to strong industrial support, is their size and complexity. The ambition to provide everything to everybody prevailed and let them grow into complex bodies difficult to master."

https://www.inf.ethz.ch/personal/wirth/Miscellaneous/Compute...

Oberon-2, Concurrent Pascal, Active Oberon and Zonnon variants were designed by students or together with ETHZ fellow researchers.

Oberon is smaller than Modula-2, and Oberon-07 lost features on each language revision.

So from our point of view Go isn't complex.

From my point of view Go still lacks several features, which Go 2.0 will kind of address.

However, from Wirth's point of view, which after being retired was still trying to design such minimal language, Go is indeed complex.

You can see this by reading the language reports.

https://www.inf.ethz.ch/personal/wirth/Oberon/index.html

I keep coming back to a talk by Daniel J. Bernstein, that the assumptions computer science teaches about performance are wrong. His claim is for real programs most code is ice cold and a tiny percentage is hot. And that's getting worse not better as time goes on.

What important is; correctness, latency, compile time. Not raw speed.