Hacker News Reader

Comment by boondaburrah | Hacker News Reader

The requirements state "If you're using C++, a compiler that supports C++ 20" and All I'm thinkin' is it must be nice to be able to choose a modern compiler like that. Some of us are lucky to get C++14.

I'm not saying we should be stuck on old compilers forever, but in C++ land, especially when I have to integrate with other frameworks or game engines, the assumption that I can choose my compiler or will always be on latest kinda irks me. Even Qt has versions for the last few MSVC releases (though thankfully the ABI stopped changing every release after VS2015).

That being said, this still looks pretty new, and by the time it's a mature framework C++20 itself may be more available.

View on HN

I think that's a deliberate decision. They know that by the time it gains adoption even C++20 will be "old". By pinning the requirement high now, while there will mostly be early-adopters, startups, open source projects etc there's less of a cost.

On the Rust side they require a compiler released 10 weeks ago, and it is actually reasonable, thanks to Rust's strong backwards compatibility and painless auto-update.

Yeah the problem isn't nearly as pronounced for rust, since rustup exists and rust itself isn't really available on any platforms you can't just update the toolchain yourself.

C++ has a lot more tangled dependencies going on especially when you're stuck with a vendor's compiler.

Make no mistake: the problem here isn't necessarily technological.

I don't understand what would be an environment where you could fetch the latest rust from internet but not the latest clang. I do my builds on centos:8 (well, rockylinux now) and it has access to the latest GCC 11. On Debian derivatives llvm itself provides up to date repos and on Windows, llvm-mingw works perfectly.

Generally, an environment where you can't use clang /at all/. There are many C++ compilers.

but this does not make sense. If you can't even change the C++ compiler you use you can't write non-C++ code (e.g. Rust) either.

Otherwise let me just fork Clang into the "Gnalc" compiler for the "Sulpsulpees" language which happens to be exactly compatible with the programming language that the clang++-13 binary supports. Takes me a whole 15 minutes, most of which will be taken by forking the LLVM repo on github, and I can guarantee than porting to it will be less effort than porting to Rust. I can even provide the backing of a proper non-profit foundation established on two continents for your legal team's needs.

The reason you can't use clang is not a technical one, but that you are /required/ to use the platform's provided C++ compiler.

And yes, you are making my point. We are in violent agreement.

You can't write Rust either, which is why C++ support would be initially exciting, until you learn you can't use just any C++ compiler and the one you can use is excluded.

Who has such stupid requirements ? What's the "platform" compiler for something that provides GCC up to 11, like centos ?

Embedded stuff usually, game consoles. Also if you have an Enterprise SKU of Visual Studio it costs real money to upgrade. Maybe your company has purchased a compiler suite you have to use. Maybe you have to link against proprietary libs that were only provided for a certain MSVC ABI.

But you originally said: "Yeah the problem isn't nearly as pronounced for rust,"

It does not make sense: the problem is even worse for rust in that case, since you cannot even use it ?

Exactly, that's why one would get excited for C++ support.

However, I realise the point is moot since there would be no way to compile the library. I've been living too long in "Compiles to C" languages this month I guess.

C++ the language also has pretty strong backwards compatibility. It's also trivial to install a new Clang version on most systems. But it certain spaces that's not what matters. Maybe you are only allowed to use That One Certified Compiler from 15 years ago and getting a certification for a newer compiler is not feasible. Or maybe you're on a system where the C++ standard library is part of the system and so you cannot use newer language features because that would require raising the minimum required OS version (I remember that some parts of the C++ standard library are not available if you compile for older macOS versions, for example).

It's usually very old projects that are stuck with old C++ versions, no? I mostly work in embedded, and even there, new GCC or Clang versions are rarely hard to pull in.

Reply on news.ycombinator.com