[tsimionescu]

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.

[jstimpfle]

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).

[tsimionescu]

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.

[Joker_vD]

> 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.

[leecommamichael]

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?

[tsimionescu]

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.

[lallysingh]

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.

[leecommamichael]

> 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.

[edoceo]

Maybe cause that comment up thread reads like it was written by a zealot rather than presenting well reasoned arguments.

[lokar]

Engineering details matter, a lot.