> too long build times, hard to debug templates, etc.

These are symptoms of language issues.

And hopefully somewhat mitigated by modules once they land and (if it happens) everyone migrates.

Asking out of total ignorance: How exactly do modules interact with templates? Is template specialization restricted to the module where the template is defined? If not, I don't see how modules could help much.

Still ongoing design. This is the Microsoft view of them

https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-modules...

Regarding templates, the approach is similar to the deprecated export keyword, so partially compiled templates and inline functions are stored in the metadata database used by the compiler for modules.

I love how the second and third paragraphs describe modules as if they were some sort of novel, perhaps even futuristic, language feature that no programmer has ever seen before. “Oh, it's totally not like we're catching up with what other programming languages had for decades.”

The problem is that in the C culture practically ignored everything that was done in computing up to the late 70's.

Bjarne was of course aware of modules, being brought on Simula and other programmer friendly languages, but then he had to make C++ code fit into UNIX linkers that only knew about AT&T Assembly and C binary formats.

So no modules there, and along the years you got a culture of developers, specially those that only learn on the job, that never learned about modules and its history.

You see it happen also when cache friendly code and RAII get discussed.

Those things were also possible outside the C family of languages, before they won the market. So most millennials think that they are some special language capabilities only possible in C and C++.

> You see it happen also when cache friendly code and RAII get discussed.

To be honest, I can't talk intelligently about cache-friendliness at all. I know that there exist models of computation (say, for complexity analysis purposes) that explicitly take memory hierarchies into account, but I've never seen them actually used on anything but the simplest data structures and algorithms.

With respect to RAII, I think the main benefit isn't cache-friendliness, but rather deterministic destruction - you can't delay relinquishing a scarce resource that someone else might want to use.

> So most millennials think that they are some special language capabilities only possible in C and C++.

I'm a millennial, and have to admit with shame that I grew up thinking C++ is the best thing ever. But it's possible to recover from it. :-)

> With respect to RAII, I think the main benefit isn't cache-friendliness, but rather deterministic destruction - you can't delay relinquishing a scarce resource that someone else might want to use.

I never said it was related to it, I said it was the other feature many think it is C++ specific, or introduced via C++.

Ada also has RAII via controlled types and Object Pascal also had destructors when it was introduced.

Functional programming languages that allow for rich macros, support trailing lambdas or currying also allow for RAII like implementations using those features.

For example, with-open-file in Common Lisp.

> but I've never seen them actually used on anything but the simplest data structures and algorithms

Take a look at a typical performance-oriented GPU coding, cache is the major analysis parameter there. Data structures are mostly 2D and 1D arrays, but they may be scrambled in a very complex way, and the algorithms are arbitrarily complex.

Thanks for the pointer. Will have a look.

"I like work; it fascinates me. I can sit and look at it for hours." -- Jerome K. Jerome. Especially when it's the high priests of the C++ orthodoxy reinventing the wheel 30 years late.

Idk dude, after programming in swift for some time, I feel like c++ can't really become a modern language.

Agree that swift (and other languages like Rust for that matter) offer some very nice advantages over C++. However, C++ is so well established and has a rich collection of libraries and integrations. You can write a library in C++ and ship it on nearly everything. You can also optimize the parts of your system that are well-suited to a systems-language like C++ and then easily expose them in other languages like Python, Ruby, Go, Swift, etc. via their C-bindings.

We can't say that (yet) about Swift and Rust. In 3-5 years I think this is going to be a very different conversation, though.

In my mind, C++'s flexibility is both its greatest benefit and its greatest danger. You can do almost anything, and there are so many ways to do it. I agree this is a "problem" that's likely not going to be fixed. You can ask your fellow developers to read Scott Meyer's Effective (Modern) C++, you can go to meetups, listen to the wisdom of the steering committee, etc. but at the end of the day it really boils down to the fact that your team needs to be committed to being resilient and responsible. That's true in any language, but much more so in C++.

Rust actually has a really nice embedded library story, and I've already seen a few things in Ruby or Go that have started using Rust libraries for performance. https://github.com/BurntSushi/rure-go for example, just to pick something that's crossed my feeds recently.

Not sure about Swift, I haven't really been paying attention in that space.

That is what eventually made me more focused on JVM and .NET languages, with C++ only being used only for lower level infrastructure code if at all needed.

Writing proper code in C++ requires, as you say, "your team needs to be committed to being resilient and responsible", which just doesn't happen on my little piece of the world.

So using it in personal projects, yeah. At work, not really.

At least two production users of rust are explicitly embedding rust in Ruby. The Node bindings (neon) are really great too.

Even then, in C++ you still need to expose a C interface, so it feels at least on even footing with Rust. But of course, I am biased...