Hacker News Reader

Comment by BinaryIdiot | Hacker News Reader

> Concepts, modules and coroutines were perhaps the three most anticipated features

Were they? They're great and all but from a practical standpoint I'm most excited about networking being baked in. I do almost nothing nowadays that doesn't require some form of networking. Now I can do it without bringing in any extra dependencies beyond the STL? And it's portable? Yes please!

I'm not a huge C++ developer. Maybe if I was other things would be more important to me. But adding in networking makes me want to use the language again.

View on HN

Networking is a very particular set of features that you only need if you are, well, doing something with the network. I'm not and probably never will, for example. But concepts and modules (and perhaps coroutines) were general features that would have potentially benefitted every single problem domain, since they are fundamental to how you use the language, not what you are trying to do with it.

If you are talking about networking TS based on boost:asio, it is much more than just networking. It is a full fledged multi threading library.

Fair enough. But honestly the lack of modules never kept me from doing C++. It was more the lack of a modern standard library. Pretty much every modern language has a way of conducting networking with their standard library.

Though you have a great point. Really miss using C++ and while it still has tons of awesome ideas / stuff parts of it are just really far behind many other languages. I'd love to see modules come in and someone create a good package manager that uses them.

Doing networking in the standard library without introducing a proper async framework is just more madness. Polishing off promises and futures, and getting coroutines nailed down, would have made introducing an intuitive network library a doddle.

Instead we'll get something carved out of ASIO, which is a complete mess full of gross unintuitive APIs and callbacks.

What's wrong with ASIO interface? My only issue with it is that once a socket is bound to an io_service it can't be easily rebound to another one.

For many applications where C++ is used, promises and futures introduce unnecessary overhead. On the other hand an ASIO-like interface works just fine.

Additionally, ASIO, and by extension the network proposal, have transparent opt-in support for futures via a special callback type.

Example terrible API: You have to create a socket for a new connection before calling async_accept. Try using this with coroutines.

> opt-in support for futures via a special callback type.

Which is ugly. The coroutines opt-in as well. Coroutines actually have the potential to be faster than callbacks.

At the places that I have worked the compile (and link time, even with using something like Incredibuild) time is a huge factor. Being able to have modules would have improved this significantly.

Coroutines would also have been useful in many circumstances.

Reply on news.ycombinator.com