Hacker News

The blog post basically said exactly this:

> IMO the blame here doesn't lie on gcc or clang; it lies on the standard. that is, the standard is wrong and should be updated to make this implementation-defined.

Yes. And Hasn't this always been the case? Before GCC and Clang took over everything there were plenty of C / C++ compilers from Intel, Visual C++ etc.

Yes

The only truth is shipping code

Specs are secondary

I laughed so hard at this....

Eh, both are about the same? With the source-level API changes, you can patch the source code or, you know, just keep using the already existing binaries, or keep using the old compilers. But if you break ABI, you can't keep using those already existing binaries, you need to start upgrading in bulk. Using the new compilers. That also probably have some source-level API changes. Oh dear.

I half-agree with this. People occasionally argue that, e.g., Rust won't be suitable for production use until it has two fully independent mature implementations, and I consider this a silly requirement that doesn't serve any real purpose. On the other hand, once multiple separate implementations are already in widespread use, there's immense value in working out a least common denominator of language features and standard library APIs that work everywhere, so that library authors can write portable code that users of any implementation can depend on.

Of course, it's always possible that the standardization body doesn't in practice do a very good job, as seems to maybe be the case with the C++ committee. Also, I'm only talking here about technical considerations, not governance ones.

The working group said bring us a paper with the exact proposal, I haven't seen an update where someone did.

I've tried it, and no. Honestly C++ gets so many complaints partially because so many people use it. It deserves a lot of it.

I just finished my work on a 2.5 yr rust project that was very low-level. The problems I had with it were that the language and library designs will always be behind the current state of the art in performance. Hardware and systems APIs change quickly, and they can shift the optimal design decisions easily for different workloads. E.g. chiplets on your CPUs can change where you want to put your io_urings, their workers, and any relevant sq_poll threads. Your NIC's DMA/TLS facilities can change your memory pool policies - do you want zero-copy APIs, or is the copy required anyways because of all the CPU-local work you have to do? Do you preallocate and feed giant buffers to register with the io_uring, or do you need to share your memory pool with the rest of the application? Do you use a single mutex for the pool, a hierarchy between thread-local and global? Do you also use a chiplet-local allocator?

What's nice about C++ is that your fight isn't against the language and runtime. They don't care what your situation is. They'll work. You do have to assemble it, and other languages make some assemblies a lot easier to do.

Yes Rust and its libraries are getting better. But so's C++.

Systems programming is very much about minutiae, to a great extent. And this particular detail will affect any systems language, one way or another. Every language has to decide if the calling convention is part of the function signature or not, and every systems language then has to decide whether it allows C functions with the same name as native functions or not. The C++ standard decided to allow this, which actual C++ compiler implementers decided to ignore for whatever reason, but that's just a bug, of which, again, you'll find many others if you actually do systems programming.

I'll also note that "Odin, Rust, Zig" is a weird enumeration - neither Zig nor Odin are anywhere near being a realistic option for a new complete system. Odin is so obscure it doesn't even have a Wikipedia page. Zig is still pre-1.0 and often makes breaking changes to core libraries.

Lindy's Law says C will be around longer than any of that lot. Although I wouldn't bet against Rust now that it's used for Linux drivers.

Unfortunately I'm a GPU programmer. C++-based CUDA/HIP is still the standard regardless of how much people would rather use Rust to program GPUs.

Only if you don't code for living.

Consider Nim too!

on the standard? or the compilers? or both?