> Modules are the answer, but it seems nobody cares enough to get them in the standard or, more likely, it's just too hard a problem.

Aren't modules especially limited with the mentioned problem of templates? If I have a vector of a custom type, I still have to instantiate it in every file that is using this type, I don't think modules help much here, they reduce the amount of time parsing, not instantiating if I understand correctly.

We'll need to significantly change the way we handle templates in compilers to get significant improvement.

Most of the time the same template with the same parameters are instantiated multiple times. If modules work, there should be only one compilation.

"There are talks from Google who invested heavily into modules using clang and got gains, but as far as I understand they fixed those issues only for themselves"

I thought Google fixed the C++ compile time problem by inventing Go?

Inventing a new programming language is hardly sufficient if your existing codebase is 10M lines of c++ :).

If we're talking about Google, I think the number is at least one order of magnitude larger. A year ago Google estimated it at 2 billion lines, though that appears to include all languages (not just C++): https://www.wired.com/2015/09/google-2-billion-lines-codeand...

If the new language has good interop with C++ then it can be.

Good interop with C++ means parsing and instantiating templates. This means you have a C++ compiler.

It doesn't help at all as soon as you need to do anything that requires compiling those 10M lines of legacy code (think bug fixes, for example).

No language has good interop with C++.

The D language, while not 100% C++ compatible, takes a pragmatic approach to C++ interop (https://dlang.org/spec/cpp_interface.html)

Not even C++ has good interop with C++, given how underspecified it is. Is that library built with MinGW or with Visual Studio?

Last I looked at Go is was missing pinning and few other things that are necessary for interacting with native code.

No they invented their own build system and tools (Bazel). Although some of the tools are open source the true distributed compile scaling stuff I think is still not.

No, they invented Blaze (general purpose caching build tool, open-sourced as Bazel).

Go is hardly a replacement for C++. Garbage collection, no templates, no const, etc.

Modules are on the good track, looking from the latest CppCon and LLVM talks,they have progressed a lot on their internal use.

I am confident that by C++20 they will be available.

The main problem will be the adoption by major libraries.

Correct me if I'm wrong, won't we need an updated OS tool chain, i.e. kernel headers and libc/libstdc++ fully adjusted? That will take some work...

Libstdc++ is normally distributed with the compiler, so it will be updated as required by the standard.

Regarding the libc and other headers, modules will still fullly support include files, so that won't be an issue. You should be able to include headers and export them as modules.

Kernel/system headers are C, or part of a compiler SDK.

libc and libstdc++ are part of the compiler runtime, ie. will be updated together with it.

Just kind of.

Kernel headers are only an issue on free UNIX like OSes, on other OS what matters is what the SDK provides.

So at least in what concerns Apple, Google, Microsoft and every other commercial vendor OSes, don't expect a big issue having their SDKs updated when they start supporting modules.

The problem is getting the BSD, Linux and open source libraries without a specific agenda to adopt them.

Clang uses "module maps" to turn existing header-based libraries into modules. So, theoretically, your system compiler could include a module map for all of the system headers. I don't know if module maps are going to be part of the standard, though.