The whole point of C++ is that it enables writing more powerful libraries, capturing semantics in libraries that can then just be used. C++ is still quite a lot more powerful for this purpose than Rust. Rust will get better at it, over time, but it has a long way to go and C++ is not siiting still.

Rust is still a niche language, and if its rates of adoption and improvement do not keep up, it will remain a niche language, and fade away like Ada.

I cannot imagine a serious programmer switching from C++ to Go. If you can, you have a much livelier imaginary life than I do.

The Ada partisans are all out in force here in this thread to defend Ada, all four of us. haha... For what it's worth, niche as Ada may be, it's an _important_ niche. It remains widespread in safety-critical applications, and isn't going anywhere anytime soon. It's really good to see Rust taking lessons from Ada/SPARK in the area of formal proofing! If any language is going to threaten C++, it looks like Rust. I don't expect an Ada resurgence to happen, unfortunately.

> I cannot imagine a serious programmer switching from C++ to Go. If you can, you have a much livelier imaginary life than I do.

This got a laugh out of me.

A large majority of Ada partisans found their corner in Java, C# and C++'s type system improvements over C, and made the best we could from the sour grapes of C's copy-paste compatibility.

Calling myself an Ada partisan is a bit of a stretch. I've recently begun using it for embedded development, which is a domain almost completely dominated by C. That's the angle I'm coming in from.

It depends on each one naturally.

For me, coming from Turbo Pascal 3 - 6, it allowed me in 1993 to use a language with a similar level of safety and language features, instead of having to deal with PDP-11 constraints.

I was always the weird kid that asked the professors if I could deliver C projects written in C++ instead, which thankfully some of them did accept.

Specially given that at my degree, C was already out of fashion by the early 90's. First year students got to learn Pascal and C++, and were expected to learn C from their introduction to C++ programming.

> Rust is still a niche language

Only just barely at this point. It has significant projects from a lot of the largest companies (Google, Microsoft, Amazon, etc). Firefox is using it, Dropbox is using it, Red Hat is using it.

In five years it might be just barely a niche language. In ten, if it catches on, it won't be.

If it does, its users will have come over from Java, C#, and C.

Is this the "no serious programmer" fallacy?

No true hn commenter would make such a mistake.

From what I can see, the whole point of C++ is to wrap existing C libraries and call them OO :-)

No, using a library is not halfway to using a different language.

Languages exist to allow you to define your own layers of abstractions. The language choice ideally reflects what abstractions are useful for your project.

> But at that point you're already halfway to using a different language

This statement makes no sense at all. Using a third-party library that's not specified by the same ISO standard that specifies the core languagr does not create "a different language".

It just means you're actually using the programming language to do stuff.

This isn't the case even if someone uses a toolkit that relies on preprocessor tricks to give the illusion of extending the core language, such as Qt.

C++ is designed for people to make nice libraries. Unlike other languages there is nothing special about the standard library (no magic language hacks). All libraries are first class citizens by design.

Good luck implementing something like std::is_standard_layout without "magic language hacks". No, not all libraries are made equal and std is part of the language now, there is no way back

You've cherry-picked a type trait as your example, which arguably could be a core language feature made to look like a third-party module.

Meanwhile, do you believe it's hard to implement a container?

And no, adding cruft to the STL is not a one-way street. See for example the history of C++'s smart pointers.

It is pretty hard to implement a container with all the precise invariants and guarantees that the Standard requires.

But more to the point, your implementation might still not be as fast as the standard library one, because the standard library can make assumptions about the compiler that you cannot in portable code - what is UB to you might be well-defined behavior to stdlib authors. Thus, for example, they might be able to use memcpy for containers of stdlib types that they know are safe to handle in that manner.

A look into the type_traits header reveals that is_standard_layout is implemented with standard C++.

This is absolutely false.

https://github.com/llvm-mirror/libcxx/blob/master/include/ty...

It checks if a non standard feature is available, otherwise falls back to a standard implementation.

My argument was that it was possible to implement it with standard C++.

There's no way to implement that type trait using standard C++. The implementation does check if a non-standard feature is available, and if not it delegates to is_scalar which in turn delegates to is_enum which in turn delegates to is_union. is_union can not be implemented in a standard conforming manner without compiler support and libc++ unconditionally returns false if compiler support is not available, which does not conform to the standard.

Lack of tooling for HPC, GPGPU, mixed language graphical debugging across Java and .NET, native support for COM/UWP, game engines like Unreal, CryEngine and Unity.

Many libraries only expose C or C++ APIs. Some of these libraries are hard requirement, like OS kernel APIs or GPU APIs.

Insufficient SIMD support in other languages, Intel only supports their intrinsics in C and Fortran.

Tools for C++ are just too good, IDEs, debuggers, profilers.