Give how default gcc and clang are, along with the recommendation to update the standard instead of gcc and clang, it sounds like the standard is noncompliant with standard C++
Standard in the sense of commonly used or supplied
> 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.
It's about language *linkages*, not about extern "C" vs C++ linkage.
It's about stdcall, cdecl, fastcall, vectorcall, watcall, and other calling conventions, which should be in the type. And they are.
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.
Hot take: I feel like a lot of the original value of language standards was to unite multiple proprietary implementations of compilers/runtimes/etc. from different vendors, each of which had incentives to add non standard features to attract customers and keep them locked in. This has been significantly diminished in the last decade or two now that most languages have high quality open source implementations - now you can simply port your compiler of choice to the platform you need.
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.
> 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
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.
If you're starting a new project and can afford it, please for the love of the children, use a different systems language. In so many ways Odin, Rust, Zig, whatever are better. There will be growing pains with respect to collective knowledge and performance, but they are surmountable.
Context: I am a programmer and educator. I am so tired of informing people of these minutiae.
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++.
On embedded, your fight totally is against language and runtime. Since you cannot gave conformant freestanding C++ without exceptions, rtti and most of STL, "using c++" on embedded always turns into "using gcc" or "using clang" — their mutually compatible, but completely standards non-conformant extensions that make writing for embedded reasonable to even attempt. At that point, is the language still c++?
Meanwhile, both rust and zig will gladly compile your standalone function into standalone binary.
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.
To be fair, Odin _had_ a Wikipedia page and it has been removed because of... people with whatever interests. But I'm still agreeing with your general point. I use C/C++ because it seems to be the least friction option to me overall, and I don't want to deal with language but simply focus on my actual compute problem. (Given that, I spend an unreasonable amount of time in silly fights about language).
I've read about some drama with Odin's Wikipedia page - but I don't think that contradicts my point. If your language community can't even defend a Wikipedia page, you're an obscure language that people can't be expected to choose that easily. That doesn't automatically mean it's a bad language, but it does make it weird to recommend it in the same breath as Rust. It's like saying "choose a language like APL or C or Java" - one of these is not like the others.
> Every language has to decide if the calling convention is part of the function signature or not
Well, of course it is. If you get the calling convention wrong, then you can't actually reliably call the function. I've seen this in e.g. Win32 — pass the function with the wrong calling convention as your callback, and it will dutifully thrash your stack.
The only other option is "pretend that there is only single calling convention that everyone uses" which is apparently somewhat works on platforms that are not 32-bit x86, but only mostly.
> The C++ standard decided to allow this,
Decided to prohibit, actually.
> which actual C++ compiler implementers decided to ignore for whatever reason,
Because it's UB anyway so why bother detecting it, and it mostly works most of the time when people use it, so again, why bother prohibiting it? No promises on keeping things working in perpetuity, of course.
I'm talking about design flaws, not engineering details. I would appreciate if you would respond in spirit. I do think the list I gave is odd, and it is so because it's kind of a mashup of recent pop-culture things. I'm literally just appealing to people to attempt to use something designed with the benefit of 50 years of hindsight. Why am I being downvoted?
I've already pointed out that there is no design flaw here, just an engineering detail plus a non-technical detail (standard vs implementation). Any systems language needs a way to call C functions, and the question of whether a native function is allowed to have the same name as a C function or not is an engineering detail, not a design flaw.
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.
You're getting downvoted because your argument is cosmetic, egotistical, and useless. Can you give an objective separation between design flaws and engineering details? One that has zero ambiguity: if I give 100 engineers your criteria and then ask them to categorize 100 different points against it, would give exactly the same results? And would that distinction actually correlate to a historical analysis of programming languages' effects on software project success metrics?
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.
> You're getting downvoted because your argument is cosmetic, egotistical, and useless.
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?
I've been writing C++ for embedded systems the past year or two.
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.
The dialects issue is why I avoid interviewing in C++, because inevitably it turns out the interviewer has some weird view of what "C++" is and doesn't realize it. Years ago I had an interview in "C++14" that required std::optional (C++17) as implemented by a C++14 compiler with only experimental, nonstandard support. In another case, an interviewer on the LLVM team vehemently disagreed with me that you could legally implement std::atomic types with mutexes, as I was going over a story about fixing issues in an awful stdlib that implemented them with mutexes.
This kind of thing doesn't happen when I interview in other languages.
Java was the 800lb gorilla thanks to Sun's marketing.
Write Once Runs Everyone has been the promise of several bytecode formats since UNCOL in 1958, with UCSD Pascal being the most famous one until Java came to be.
Smalltalk was already taking off when Java came to be, it had a role similar to .NET on Windows, on OS/2, with SOM (OS/2's version of COM), doing C, C++ and Smalltalk.
All IBM Visual Age IDEs were written in Smalltalk, however it was exactly IBM alongside Oracle that were the very first to jump onboard to the Java ship.
Thus one day of the other, Smalltalk was out, and Java in.
Eclipse started as a rewrite from Visual Age into Java, and many of the Java early frameworks were ports from Smalltalk.
Also note that while Java has a C++ like syntax, its execution model is closer to Smalltalk and Objective-C, thus why it was such a great fit for Sun, acquiring StrongTalk and re-purposing the JIT compiler into Hotspot.
== Long-ago, Smalltalk systems could be file-copied from say win to mac to unices and would just work.
== Not standardized. Language vendors used proprietary code to lock-in customers and that fragmented the skills base. Skilled Smalltalk-A programmers were not-so-skilled with Smalltalk-B.
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?
They insisted that it wasn't legally possible and no one would ever do that, but std::atomic<T>::is_lock_free [0] exists precisely because implementers were doing it. The only case that anyone was ever likely to encounter AFAIK was atomic structs >= 16 bytes on MSVC because they couldn't use cmpxchg16b for reasons.
I had been using a truly awful stdlib on an embedded platform whose implementers saw that freedom as a license to implement all atomics with mutexes. I assume it was because they couldn't be bothered to write new implementations for every platform they supported, so they'd write the basic primitives and got the rest of the implementation "for free". This isn't even close to the dumbest decision they made.
Obviously that wasn't acceptable for any real use, so I wrote up a better implementation, sent it to the vendor as a patch to save their other poor customers the effort, and used it as a one line example in a larger list on my resume that the interviewer seized on. It's not uncommon for a FAANG interview to be adversarial like that.
The Zig group claims that Zig can interop with C based libraries w/o too much work. It's one of the reasons I'm digging into it now. But I don't know anything about CUDA and have only done trivial Zig<=>C tests (like my Zig code working with libpng) so far. Are their claims BS? Is Zig just not mature enough? Something else?
The CUDA/HIP APIs are mostly C-like APIs but are really C++ language extensions. e.g. you need triple angle brackets when calling a GPU kernel. The compiler turns that into placing the kernel onto the GPU and running it.
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.
> you need triple angle brackets when calling a GPU kernel. The compiler turns that into placing the kernel onto the GPU and running it.
It all boils down to calling CUDA runtime or driver APIs. Compiler just sprinkles fairly trivial amount of syntactic sugar, and under-the-hood glue code. One can launch GPU kernel from a pure C source file compiled with gcc.
> The GPU kernel code itself needs to be compiled and for CUDA that is done with the proprietary nvcc, which is clang-based.
nvcc is not the only option. Clang itself can compile most of existing CUDA code just fine, and the rest usually needs minimal porting.
Also, nvcc is not based on clang. It may use it as the host compiler, but that's the extent of its involvement with clang. IIRC, their front-end used to be based on EDG.
> HIP is better because it's an open-source llvm backend/frontend
CUDA and HIP share most of the front-end code in clang, so CUDA compilation with clang shares the same benefits. What's missing is PTX to SASS assembler, which creates the actual GPU binary, and that part is proprietary to NVIDIA.
AFAIK PTX compilation is the bit that is not mature in the Rust CUDA ecosystem as well, because it has to be reverse engineered rather than simply translated.
My guess is that Zig cannot be considered mature until someone has written an application in it that contains a Lisp interpreter. I'm banking on
Ghostty. Your move MH ;)
Give how default gcc and clang are, along with the recommendation to update the standard instead of gcc and clang, it sounds like the standard is noncompliant with standard C++
Standard in the sense of commonly used or supplied
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....
It's about language *linkages*, not about extern "C" vs C++ linkage. It's about stdcall, cdecl, fastcall, vectorcall, watcall, and other calling conventions, which should be in the type. And they are.
https://archive.md/lBvFq
> gcc and clang can't change their behavior because that would be a breaking ABI change
It's an API change. Breaking source code is generally an even bigger deal than breaking binary compatibility.
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.
Hot take: I feel like a lot of the original value of language standards was to unite multiple proprietary implementations of compilers/runtimes/etc. from different vendors, each of which had incentives to add non standard features to attract customers and keep them locked in. This has been significantly diminished in the last decade or two now that most languages have high quality open source implementations - now you can simply port your compiler of choice to the platform you need.
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.
> 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
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.
But looking at this, it seems like something similar happened 12 years ago[1]. Why hasn't it been changed?
[1]https://cplusplus.github.io/CWG/issues/1555.html
The working group said bring us a paper with the exact proposal, I haven't seen an update where someone did.
Is it because the impact of the change is too big? I mean, is that why it's hard to submit a proposal?
Last time I looked "submitting a proposal" to WG21 involved attending in person. Has something changed recently?
I'd bet that nobody just cares enough, but idk
If you're starting a new project and can afford it, please for the love of the children, use a different systems language. In so many ways Odin, Rust, Zig, whatever are better. There will be growing pains with respect to collective knowledge and performance, but they are surmountable.
Context: I am a programmer and educator. I am so tired of informing people of these minutiae.
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++.
On embedded, your fight totally is against language and runtime. Since you cannot gave conformant freestanding C++ without exceptions, rtti and most of STL, "using c++" on embedded always turns into "using gcc" or "using clang" — their mutually compatible, but completely standards non-conformant extensions that make writing for embedded reasonable to even attempt. At that point, is the language still c++?
Meanwhile, both rust and zig will gladly compile your standalone function into standalone binary.
These are legitimate complaints, and I meant for "if you can afford it" to do a lot of lifting in my first comment.
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.
To be fair, Odin _had_ a Wikipedia page and it has been removed because of... people with whatever interests. But I'm still agreeing with your general point. I use C/C++ because it seems to be the least friction option to me overall, and I don't want to deal with language but simply focus on my actual compute problem. (Given that, I spend an unreasonable amount of time in silly fights about language).
I've read about some drama with Odin's Wikipedia page - but I don't think that contradicts my point. If your language community can't even defend a Wikipedia page, you're an obscure language that people can't be expected to choose that easily. That doesn't automatically mean it's a bad language, but it does make it weird to recommend it in the same breath as Rust. It's like saying "choose a language like APL or C or Java" - one of these is not like the others.
> Every language has to decide if the calling convention is part of the function signature or not
Well, of course it is. If you get the calling convention wrong, then you can't actually reliably call the function. I've seen this in e.g. Win32 — pass the function with the wrong calling convention as your callback, and it will dutifully thrash your stack.
The only other option is "pretend that there is only single calling convention that everyone uses" which is apparently somewhat works on platforms that are not 32-bit x86, but only mostly.
> The C++ standard decided to allow this,
Decided to prohibit, actually.
> which actual C++ compiler implementers decided to ignore for whatever reason,
Because it's UB anyway so why bother detecting it, and it mostly works most of the time when people use it, so again, why bother prohibiting it? No promises on keeping things working in perpetuity, of course.
I'm talking about design flaws, not engineering details. I would appreciate if you would respond in spirit. I do think the list I gave is odd, and it is so because it's kind of a mashup of recent pop-culture things. I'm literally just appealing to people to attempt to use something designed with the benefit of 50 years of hindsight. Why am I being downvoted?
I've already pointed out that there is no design flaw here, just an engineering detail plus a non-technical detail (standard vs implementation). Any systems language needs a way to call C functions, and the question of whether a native function is allowed to have the same name as a C function or not is an engineering detail, not a design flaw.
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.
You're getting downvoted because your argument is cosmetic, egotistical, and useless. Can you give an objective separation between design flaws and engineering details? One that has zero ambiguity: if I give 100 engineers your criteria and then ask them to categorize 100 different points against it, would give exactly the same results? And would that distinction actually correlate to a historical analysis of programming languages' effects on software project success metrics?
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.
> You're getting downvoted because your argument is cosmetic, egotistical, and useless.
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.
Maybe cause that comment up thread reads like it was written by a zealot rather than presenting well reasoned arguments.
Engineering details matter, a lot.
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.
C will outlive all of us.
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?
I've been writing C++ for embedded systems the past year or two.
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.
All modern C compilers are written in C++.
C also has dialects.
Yes, we switched from C98 to C11 and are about to adopt MISRA C 2023 (with exceptions).
The dialects issue is why I avoid interviewing in C++, because inevitably it turns out the interviewer has some weird view of what "C++" is and doesn't realize it. Years ago I had an interview in "C++14" that required std::optional (C++17) as implemented by a C++14 compiler with only experimental, nonstandard support. In another case, an interviewer on the LLVM team vehemently disagreed with me that you could legally implement std::atomic types with mutexes, as I was going over a story about fixing issues in an awful stdlib that implemented them with mutexes.
This kind of thing doesn't happen when I interview in other languages.
It seems like the history of programming languages since the 1980s has mostly been people trying to avoid C++.
First languages with run-times and dynamic types, and more recently lower levels of abstraction (Go, Rust).
I was there, and C++ was all over the place on Windows, OS/2, Mac OS, UNIX/CORBA.
It was FOSS with its set of coding guidelines, that gave C a new wind.
Languages with runtimes and dynamic types go all the way back to Lisp and Smalltalk.
> Languages with runtimes and dynamic types go all the way back to Lisp and Smalltalk.
Java was the 800lb gorilla though, wasn't it? Because it promised portability.
Why did Smalltalk not take off?
Java was the 800lb gorilla thanks to Sun's marketing.
Write Once Runs Everyone has been the promise of several bytecode formats since UNCOL in 1958, with UCSD Pascal being the most famous one until Java came to be.
Smalltalk was already taking off when Java came to be, it had a role similar to .NET on Windows, on OS/2, with SOM (OS/2's version of COM), doing C, C++ and Smalltalk.
All IBM Visual Age IDEs were written in Smalltalk, however it was exactly IBM alongside Oracle that were the very first to jump onboard to the Java ship.
Thus one day of the other, Smalltalk was out, and Java in.
Eclipse started as a rewrite from Visual Age into Java, and many of the Java early frameworks were ports from Smalltalk.
Also note that while Java has a C++ like syntax, its execution model is closer to Smalltalk and Objective-C, thus why it was such a great fit for Sun, acquiring StrongTalk and re-purposing the JIT compiler into Hotspot.
== Long-ago, Smalltalk systems could be file-copied from say win to mac to unices and would just work.
== Not standardized. Language vendors used proprietary code to lock-in customers and that fragmented the skills base. Skilled Smalltalk-A programmers were not-so-skilled with Smalltalk-B.
== Not free as in beer.
What was the disagreement on the atomics issue?
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?
They insisted that it wasn't legally possible and no one would ever do that, but std::atomic<T>::is_lock_free [0] exists precisely because implementers were doing it. The only case that anyone was ever likely to encounter AFAIK was atomic structs >= 16 bytes on MSVC because they couldn't use cmpxchg16b for reasons.
I had been using a truly awful stdlib on an embedded platform whose implementers saw that freedom as a license to implement all atomics with mutexes. I assume it was because they couldn't be bothered to write new implementations for every platform they supported, so they'd write the basic primitives and got the rest of the implementation "for free". This isn't even close to the dumbest decision they made.
Obviously that wasn't acceptable for any real use, so I wrote up a better implementation, sent it to the vendor as a patch to save their other poor customers the effort, and used it as a one line example in a larger list on my resume that the interviewer seized on. It's not uncommon for a FAANG interview to be adversarial like that.
[0] https://en.cppreference.com/cpp/atomic/atomic/is_lock_free
While both C and Rust compiler infrastructure used by Linux drivers is written in C++.
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.
Who is stopping you? Is it an employment concern?
This question strikes me as somewhat obtuse, but I will attempt an answer:
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.
Apple's Metal is C++ too. Like, actual, you can compile it with plain C++ compiler and a shim header.
The Zig group claims that Zig can interop with C based libraries w/o too much work. It's one of the reasons I'm digging into it now. But I don't know anything about CUDA and have only done trivial Zig<=>C tests (like my Zig code working with libpng) so far. Are their claims BS? Is Zig just not mature enough? Something else?
The CUDA/HIP APIs are mostly C-like APIs but are really C++ language extensions. e.g. you need triple angle brackets when calling a GPU kernel. The compiler turns that into placing the kernel onto the GPU and running it.
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.
> you need triple angle brackets when calling a GPU kernel. The compiler turns that into placing the kernel onto the GPU and running it.
It all boils down to calling CUDA runtime or driver APIs. Compiler just sprinkles fairly trivial amount of syntactic sugar, and under-the-hood glue code. One can launch GPU kernel from a pure C source file compiled with gcc.
> The GPU kernel code itself needs to be compiled and for CUDA that is done with the proprietary nvcc, which is clang-based.
nvcc is not the only option. Clang itself can compile most of existing CUDA code just fine, and the rest usually needs minimal porting.
Also, nvcc is not based on clang. It may use it as the host compiler, but that's the extent of its involvement with clang. IIRC, their front-end used to be based on EDG.
> HIP is better because it's an open-source llvm backend/frontend
CUDA and HIP share most of the front-end code in clang, so CUDA compilation with clang shares the same benefits. What's missing is PTX to SASS assembler, which creates the actual GPU binary, and that part is proprietary to NVIDIA.
AFAIK PTX compilation is the bit that is not mature in the Rust CUDA ecosystem as well, because it has to be reverse engineered rather than simply translated.
I don't know really.
My guess is that Zig cannot be considered mature until someone has written an application in it that contains a Lisp interpreter. I'm banking on Ghostty. Your move MH ;)
Only if you don't code for living.
Consider Nim too!
Shrug, then write a defect report?
on the standard? or the compilers? or both?
[flagged]