The difficulty here is combining multiple libraries each using its own abstractions.

For example, since the standard library does not have a Matrix class suitable for numerical applications (or maybe it does today...) using multiple libraries each with its own Matrix class is difficult. Multiple libraries are needed since one library may not contain all numerical algorithms one may require for a given app.

This is not a problem for Google where I assume everyone is using internally written code -- but is a problem for most of us.

> For example, since the standard library does not have a Matrix class suitable for numerical applications (or maybe it does today...) using multiple libraries each with its own Matrix class is difficult.

well, Python comes with a builtin "matrix-like" array type and yet it's not the one which is the most used in scientific computation.

Python provides the buffer interface, however (which `array` module implements), which links Python's buffers and memoryviews to numpy arrays to multiple other 3rd-party array-like and table-like types and structures.

.. because it's (relatively speaking) brand new?

Sure it's possible to use a non-standard "standard library". But at that point you're already halfway to using a different language so why not consider switching from C++ to D / Rust / Go?

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.

What are the hidden language hacks in Swift?

I wouldn’t call them hacks, but there are things in the runtime that you can’t implement yourself in Swift. Examples (corrections welcome):

- you can’t allocate memory and then turn it into an Swift object.

- you can’t write Decodable in pure Swift (reflection isn’t powerful enough to do “set the field named “foo” in this structure to “bar”)

- reference counts are hidden from Swift code (yes, there’s swift_retainCount to read them, but that’s documented as returning a random number (https://github.com/apple/swift/blob/master/docs/Runtime.md) because it should not be used). So, if the compiler emits more reference count logic than needed in the data structure that your library uses, there’s no way to improve on it.

There are a lot more of these, I can't find a comprehensive list unfortunately.

What are those "hidden language hacks" in Swift?