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.
Yeah this was what I thought. I remember Valve Software wrote a paper about cross platform development and said it was useful compiling with Visual C++ and gcc to shake out any iffy syntax that worked in one but not the other. Of course with performance-critical code and code that needs to run on consoles as well there will always be platform-specific stuff, but if you can get 99% of the code working across multiple compilers that's pretty good.
Context: I am a programmer and educator. I am so tired of informing people of these minutiae.
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++.
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.
Now, if we were to be talking about memory safety, that would be a very different discussion. But you only mentioned "minutia" as the problem with C and C++, so I don't even know what you were actually meaning to talk about.
Furthermore, in relation to those 50 years of hindsight - Rust and Zig actually go in very different directions on fixing C or C++'s flaws, so it seems that people actually learned very different lessons in those 50 years - and I believe neither agrees with the lessons learned by the other.
No, because the entire distinction falls apart pretty quickly into "shit I like to discuss and care about" and "shit I don't care about and don't want to talk about."
Systems programming lives and dies by the details you want to ignore. The economics of large software production are mildly affected by language design. But weaknesses there are easily overcome with engineering practices and additional tooling. Almost every complaint about C++ safety I've ever heard hasn't been a problem for me for decades, because I know what libraries, practices, and tools solve those problems. But I've yet to work with another language - and I've programmed in a shit-ton of languages - that gets out of the way as well as C++ when I want to systems-program. Even C. C is strictly lower level, but its lack of abstraction facilities gets in the way more than some of the modern numerical-type-safety stuff of C++ does.
Ouch. (sincerely) I hate to think my ego might be so large and detailed that it could be so irritating to someone through such scarce writing. Are you certain you're identifying me correctly?
> if I give 100 engineers your criteria and then ask them to categorize 100 different points against it, would give exactly the same results?
Fair point, I understand that things I find to be "unnecessary friction" were once very necessary, and are (not infrequently) still necessary today.
> Systems programming lives and dies by the details you want to ignore.
I haven't really given you much to respond to, which is my fault, but I don't think you're yet identifying what I want to ignore, because how could you if I'm not specifying myself entirely? Frankly, I was being too casual with my discourse for many of the people responding to me, I see that now and graciously accept my downvotes. I'd rather have a good conversation than internet karma points, so here goes.
So let me box this in more. A lot of my students just want to get some practice with programming the computer. They want to learn some basic graphics, whether they're using the GPU or not. They want to be direct about programming the computer, and often want to use systems-languages but find C and C++ too difficult to use. It is now common for university students to complete a bachelor's degree while strictly writing Python. *This is the current against which I swim.* I do not think this is a healthy situation. I want there to be: more incentive for students to do "fine grained" (systems) programming. Ultimately, it needs to be more economically relevant _and_ to seem accessible to them. So, in my eyes, if enterprises attempt to use some of the "rounder" (less sharp) tooling *where possible*, students might think they've got a shot and can feel assured there's a point to putting in the effort to learn how to use things like pointers, allocators, profilers, debuggers etc.
I do not want C or C++ to die tomorrow, or next year, or next decade, but in my time writing these languages and their "successors" I do think there are enough meaningful improvements that we owe the next generation a chance to take ownership of something that seems a little less hairy-- even if it is so they can make it hairy and start anew. I simply want them to feel the responsibility and freedom of control.
So what are the improvements? Let's start with C. Let me preface by saying I am aware there are a few tools that are a "must" with C, otherwise you're going to get bit by things like integer conversions or memory corruption. Know your compiler-flags and tools like valgrind and you'll be okay. But what if you didn't have to learn that the hard way? Some of the new languages can put friction in the way of these mistakes, whether by way of incompatible numerical operations on mixed types, or various restrictions on what you can do with a pointer. These are small things, and I hesitate to list many more, but there are so many! I realize I won't be exhaustive enough for you, but we can take it further, sometimes bugs can be introduced via aggressive backend optimizations which operate on undefined/platform defined behavior. Again, in this case, there are languages which simply forego these optimizations by defining the behavior.
Again, I realize there are genuine losses due to these design decisions which I'm advocating for, and I appreciate the pressure you're placing against me to distinguish these from flaws. I don't mean to point at the inventors of the past and to say they just did it poorly, I simply believe the trade-offs are out of calibration now. e.g. C's pre-processor and linkage strategy is to write a bunch of little atomic things so that it all fits in memory. That is still crucial for a lot of the largest systems out there today, but for anything else PLEASE let me write something like `go run .` and be done (this is not an endorsement for Golang specifically.)
The point which inspired me to write any of this is this: the software we run could be faster and lighter if we know how to make it that way. I think C and C++ are good tools to make the absolute fastest and lightest software in a great many cases. Probably the best tools. But what about the people who just want to make a GUI application without learning the framework of the month, or the programming language of the decade? What if you want to know something you can use for the foreseeable future without investing the kind of energy it takes to be a discerning user of C or C++? We're missing out on better software because students are giving up on "finer" tools.
C++… I don’t know it well. But I’ve heard there are a lot of different dialects, to the point where it is possible that two C++ programmers might be writing in essentially different languages. How “old” is the language, in that case?
We use a very conservative subset of C++, almost like C with inheritance. We barely even use templates. We try to avoid allocating on the heap. The code is mostly imperative.
Since 2011, a lot of new language features have been introduced. The ones we use are things like smart pointers (that improve lifetime management) and some tweaks for better type safety.
It is said that moden C++ enables a functional programming style. I have never actually seen anybody code that way (it would be hell to write and worse to read) but that could just be the niche I'm in.
What is undeniable is that C++ is so complex and has so many features that you have to choose a subset of the language to enforce a consistent style.
Also a lot of the STL (standard library functions) are deprecated in one way or another, which is a real minefield.
This kind of thing doesn't happen when I interview in other languages.
I only know them from openMP (more of a Fortran person)… without much thought my gut says that it’d be possible to implement an atomic operation with a mutex, but sort of defeating the purpose. An atomic operation is mostly expected (intended? hoped?) to be backed by some hardware atomic instructions anyway, right?
NVIDIA and AMD.
These are only two GPU manufacturers of any significance. (Intel is also a player, but not a major one.)
They supply SDKs (drivers and libraries required for software development) for their products that support C and C++ and precious little else.
There have been attempts to reverse engineer the toolchains in Rust but as I understand it they are not yet mature.
The GPU kernel code itself needs to be compiled and for CUDA that is done with the proprietary nvcc, which is clang-based. HIP is better because it's an open-source llvm backend/frontend but you'd still need to add GPU-specific support to zig/rust/whatever.
Standard in the sense of commonly used or supplied
The only truth is shipping code
Specs are secondary