Hacker News Reader

Comment by asdfasgasdgasdg | Hacker News Reader

It still boggles the mind that they made it so hard to use this stuff in terms of boilerplate. Hopefully that will all be abstracted into a library that handles io, networking, multiprocessing and synchronization so most of us can just focus on writing the bits that do stuff. But I will never understand how the std maintainers could not manage to do this when every other language is doing async await support in their standard library Io utilities.

View on HN

I think the reason it's like this is because the C++ maintainers are super focused on noticing whenever there is a choice to be made, and being careful not to make it for you. Given the option between foisting situationally bad performance on you and foisting lots of syntax and interface complexity on you, they always choose the latter. Which I suppose makes sense: C++ niche is that it's the Big Gun you pull out when there's serious work to be done. So they figure you're already going to be dealing with massive complexity anyway, and you're going to be prepared for it. May as well let give you _all_ the access rather than fumbling at the 1 yard line by making some opinionated choice that is a non-starter for somebody, somewhere.

> I think the reason it's like this is because the C++ maintainers are super focused on noticing whenever there is a choice to be made, and being careful not to make it for you

If you think that's the case, explain why I can't decide I want to pass an argument to a function in a register:

https://stackoverflow.com/q/58339165/1593077

Also, modern C++ has actually made it possible to write much more elegant code, for many delicate tasks, without sacrificing the performance benefits. So a convenient default doesn't necessarily have to contradict non-opinionated nature.

Most of that boilerplate will be hidden in the libraries which use it. Unless you are a library author I don’t know why you would care about the boilerplate-like elements from the standard— you will only use co_yield and co_await.

C++ compilers are famous for their cryptic error messages. Standard Libraries are the reason.

Lack of concepts was the reason, it will only get better now.

So far as I can see in 2026 the C++ programmers will be assuring us that (some feature from C++26) is going to fix all the awful clag in the C++23 programs which, in turn, offered (some feature from C++23, maybe it's a simpler exception mechanism) but alas instead created more clag, despite their promise to clear up the mess from C++20...

I am an old man, and so I remember when left and right every C++ programmer was excited about how the Standard Template Library was going to make everything OK and those of us who were still jeering would be writing C++ soon. How did that go?

I see it differently.

Many will keep hating C++, while ignoring that Java, .NET (C#, F#, VB, C++/CLI), Python, JavaScript, PHP, Ruby,.... all suffer from similar complexity, spread around 30 - 40 years of language evolution and ecosystems.

Others will cling to their outdated toolchains because the language owners played a Python 3 on them.

While some will understand that the world isn't perfect and make do with what is out there.

ISO C++ strongly resists simplification. It can grow. I have no doubt that every brilliant idea I see in programming languages can be added to C++ but the problem is that it can't shrink and so what happens instead is that mostly "C++ programmers" speak a dialect of C++ and those dialects become mutually incomprehensible, and so then what was the benefit of C++ as a language rather than just the abstract agreement that you could, in principle, graft every conceivable feature on to something that looks kinda like C?

An example is right in the name. Today we know that "clever" operators like the pair of ++ increment operators in C++ are a bad idea. They too easily allow mistakes to hide in plain sight, the programmer writes ++n where they actually needed n++ or vice versa, and a reviewer's brain overlooks this and so it gets shipped.

If you're playing Code Golf then these operators are a big benefit, but we aren't playing Code Golf, we're writing actual software that will be used in the real world, so explicitly spelling out what you meant is good.

As a result some modern languages deliberately do not have these operators. And e.g. as I understand it Swift actually removed these operators from the language. But C++ 20 still has both operators of course, it's just that your local dialect might forbid one or both of them.

Modern languages start from scratch.

Python 3 will stay in history as a canonical example of what happens when those wishes turn into reality.

That is the way of everything in the world.

One reason could be that C++ tends to be used more in performance-critical contexts, and frequently the abstractions present in "every other language" can get in the way of performance.

also the memory management model in c++ is much more complex - most other languages just use garbage collection to deal with reference lifetimes

garbage collection is one of the abstractions that can interfere with performance. it's out of the question for real time contexts, for example.

Depends,

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/wp/products-services/jamaicavm/

On the other hand there is real time where even malloc() is forbidden.

https://en.m.wikipedia.org/wiki/MISRA_C

The first one targets “sub-millisecond”, which is a eternity in current systems.

According to the third link:

> we observed a negative correlation between MISRA rule violations and observed faults

So, MISRA isn’t really helping with real time at all.

The second link claims pauses are capped at 10us, which (if true) is actually competing with careful use of malloc.

Hence why I stated "Depends".

It is real time enough to drive battleship weapon systems, the kind of apps where the wrong people die when a GC goes wrong.

https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-te...

The first link covers cases most simply described as "it needs to be fast, as fast as possible, but things won't go wrong if there's a random 8msec delay".

Then there's "things will go wrong if there's a random 8msec delay".

Then there's "people will die and/or property will be destroyed if there's a random 8msec delay".

I was referring only to the last two. And yes, that means no malloc.

Depends how relevant 8msec are on a battleship weapon guidance system,

https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-te...

On any case, that is the reason why I started with depends, just like everyone wants to do big data that fits into a USB floppy, there are those cases where CircuitPython would be more than enough, yet people insist in using Assembly.

In some cases only Ada/SPARK or MISRA will do, others not, yet all of them might fall under real time and embedded deployment.

No, it doesn't depend. That fits clearly into the first category, in which things do not go wrong when there's an 8msec delay.

By contrast, using a DAW with typical settings, an 8 msec delay is catastrophic within the scope of the task, even though nobody gets hurt and nothing gets destroyed.

I guess we are having a language problem here, because when we have three options to refer to, it is obvious that it depends.

On Windows that library is WinRT.

Reply on news.ycombinator.com