i don’t know how to feel about these c++20 concepts. even though i haven’t seriously written c++ for years, it’s a little sad to see the language i know and love getting so convoluted and lost in modernisation. it’s gotten to the point where i look at a modern c++ code base and all i see is rust. especially the universal trailing return types everywhere, those get to me.

On the other hand, constant improvement, incorporating things that have proven to work, is a way to not get left behind.

If C++ did not evolve it would eventually be replaced just as c++ itself replaced older languages.

But Ido recognize the feeling.

I learned C back in school and later when c++ became common I tried it and did not like the << and >> syntax.

But even though I never got into C++ I have accepted that the changes was for the better and embraced it, which probably served me well over the years as it helped me stay up to date with new developments in C# which have changed significantly since it’s birth

Concepts looks like a great idea. But the convoluted syntax is...

What's bad about it becoming Rust? That language is awesome

And it's not like C++ was ever concerned about being too complex

@12bitfloat What's bad is the syntax which is like a rusty pole in one's ass, which is also why they named it "Rust" in the first place.

Then again, C++'s design goal has always been combining the safety of C with the readability of Perl, so that's there.

@Fast-Nop Haters gonna hate I guess

@Fast-Nop ah yes, this old argument again. It's getting kinda...rusty.

@RememberMe I answered because @12bitfloat asked. Also, do you really think old issues would go away just by sitting there? That's a part of the "this argument is getting old" logic I've never quite understood.

@Fast-Nop What issues? C++ doesn't have the safety of C, it's way far ahead because of the much stronger type system and compile time features. And well written code in C++ is a pleasure to read once you know a good chunk of language features (a lot of which make code *more* readable and cleaner, not less), seriously dunno what you're on about. You get used to the syntax, which is naturally going to be complex because it makes explicit what is in implicit in C. The complexity of the syntax reflects the complexity of what it's trying to do. Complex doesn't necessarily mean bad.

Rust does the same. Lifetimes for example are implicit in C/C++, but explicit in Rust. I like things written down as they are.

The average *program complexity* of C, C++, and Rust programs doing similar things is similar. C trades a simpler syntax for much greater implicit complexity, C++ and Rust make the opposite trade, with the added bonus that they enable much more powerful abstractions thus actually lowering overall program complexity (perfect forwarding in std::vector's emplace_back method is a good example of this. Zero overhead, clean af syntax, doesn't break abstraction like C would have to do.)

Note: not claiming that C++ and Rust don't have issues, they most certainly do. But the syntactical complexity is there for a reason. Can we do better while retaining the expressiveness of these languages? There's tons of research into programming language design happening on that very topic.

@Fast-Nop Repeating wrong arguments doesn't make them more correct either though

Look, nobody who knows even a bit of Rust complains about the syntax, quite the opposite actually (because it *is* really nice and thoughtful)
The only ones complaining that Rust is so unreadable are outsiders that want to put the language down for whatever reason (fear of being left behind typically)

Rust really is one of the most well designed languages I have ever seen, so much so that I have unironically thanked god for the series of unlikely events that lead to it being as it is today. (and yes I'm an atheist, but hey apparently miracles do exist)

All I'm saying is, please try to understand something before hating on it. Because there may actually be something to it...

@RememberMe Strange, I think it's the opposite. C is explicit where C++ is hiding code under the rug. It's a major reason why I don't like it, and putting ever more garbage on that dumpster doesn't help it.

@12bitfloat Yeah fear of getting left behind. Sure. Fanboys are gonna fanboy.

@Fast-Nop Ya can't teach an old dog new tricks I guess. At the end of the day it's none of my business, so whatever. I'm certainly glad I have seen the light

Well I guess you can see C++ designers are trying to make it modern and simpler as much as they can, but yeah it sure feels more and more like a plane with 300 passenger holding up with a shit ton of duct tape.

@Fast-Nop you really do have something against abstractions, huh. It's not "hiding code under a rug", it's "showing you the important stuff" while still maintaining speed. Again, I speak for well written codebases only. We've transitioned a bunch of stuff from C to C++ in our codebases and we've seen roughly the same speed with an overall increase in code clarity. Somebody wrote a C equivalent to one of the upgraded codes and it looked like absolute dogshit compared to the C++ version and had a WAY more fragile interface with WAY more frequent safety issues. C++'s stronger safety let us catch so many bugs and completely eliminated whole classes of bugs by design. And in one case the abstraction actually made the C++ code faster than the C version because type safety let us eliminate a whole bunch of runtime checks because we could get the C++ compiler to prove that they weren't needed.

Note that said C folks are very experienced at C and have been at it since the 80s.

Of course it lets you write unmaintainable soup - but then so does any other language. When comparing languages, compare what they're like when used by people who actually know how to use them.

As a hardware guy I always found C's claim of being "bare metal" and "low level" laughable, because it really isn't (the C virtual machine model ignores so many details of real hardware), but it can't abstract well enough either. So I always found it this weird middle ground of being meh at both.

@Fast-Nop wait, Perl has readability? 🤔

@iiii Yeah and C is praised for its safety. ^^

@12bitfloat I hated puzzle languages already 20 years ago. Pulling the age card is as lame as it can get.

@RememberMe Indeed, I hate overly abstracted programming styles where the code bears no relationship to the actual problem domain. Reminding you e.g. of Torvalds, that camp isn't exactly small.

@Fast-Nop your definition of "overly abstracted" might need a bit of revising. If anything, the C++ programmers I know are the most anal about performance and if something costs more than like 1-5% perf (depending on the component), it gets thrown out. And despite that we maintain a very high level of abstraction and I don't feel like tearing my hair out looking at the code.

Heck we're looking to move the not-critical-low-level stuff into even higher abstraction using a session typed channel monad and we project almost no loss in speed, though this is difficult to do because C++ isn't powerful or complex enough to express something like that very easily, so also looking at Rust (which also isn't quite there but better than C++).

@RememberMe I just don't see the value of moving to ever higher levels of abstraction. It's not a "the more the better" thing. If overdone, abstraction rather becomes obfuscation IMO, and a big reason is devs having too much project time at their hands.

Though that also depends on what you're doing. Stuff running distributed on thousands of nodes of course needs a higher level of abstraction to limit the complexity per layer.

@Fast-Nop abstraction tends to save time actually by decreasing the number of things you have to care about. Let's not mix up badly done and well done abstractions - the former is a curse and the latter is a blessing. I'm only talking about abstractions made by people who know what they're doing.

You're right about changing complexity and that's what's cool about higher level systems languages like C++ - they can scale much better to more complex scenarios. It'll handle everything from flipping hardware bits to kernel dev to complex software engineering like LLVM to eNtErPriSe scale things like Autodesk Maya to large HPC and cluster deployments just fine because it lets you control the level of abstraction as needed.

And that's why we're trying to move things higher up - so that we save time and scale to more complex workflows more easily. And we're always looking for better lower level abstractions to make code more structured and scalable at lower levels too. Hence the preference towards C++ and Rust, because they actually let you do that. We have fast DSP functions written as Rust iterators for example.