Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

An imperfect but really useful standard for whether or not a C++ feature is going to work out is how long and troublesome the standardization process is. Modules? Never happening boys, the time has passed when anyone cares. Coroutines? Break gdb forever? Keep dreaming.

Look at what they can do when it's clearly a good idea and has the backing of the absolute apex predator experts: reflection. If reflection can fucking sail through and your thing struggles, it's not going to make it.

Andrew Kelley just proposed the first plausible IO monad for a systems language, and if I wanted to stay relevant in async C++ innovation I'd just go copy it. Maybe invert the life/unlift direction.

The coroutines TS is heavily influenced by folly coroutines (or vice versa), a thing with which I have spent many a late night debugging segfaults. Not happening.

Besides, if threads are too slow or big now? Then everything but liburing is.



Not everyone is using C++ on Linux with GCC.

There are people where modules and co-routines already happened, and there is better debugging experiences out there than gdb.


I'm not sure what you're trying to say. Coroutines have been standardized in C++20 and they are fully supported by all major compilers. They are successfully used in production. I've switched to coroutines for all networking in my personal projects and I'm not looking back.


Coroutines are well supported in boost::asio and are deployed in production in more places than you would think.


A second heuristic for things that aren't going to work out well is stuff that came from Boost. Oh sure, there was a time back in the TR11 days when it was practically part of the standard. But if it's on anyone's "cool, we'll link that, no problem" list in 2025? I don't know them.


Asio is actually independent from boost and it is by far the most popular C++ networking library.


Reflection is purely a compile-time frontend thing, so is easy to roll out.

Things that affect the runtime or ecosystem of tools are obviously more complicated, especially given that those things aren't really covered by the standard.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: