Hacker News Reader

Comment by je42 | Hacker News Reader

does anybody know why this library is not based on (boost::)asio ?

I'll take a shot in the dark and say they probably value their compile times. Every boost library I've ever used has the tendency to pull in the world from a single header and take forever to compile.

ASIO can be used standalone with any C++11 compiler and the compile times are quite good.

If I should make a guess then I'd say that the original author of that part of the library either started before ASIO was standalone and/or simply has a hatred for boost (which would be unwarranted), or he/she was simply more experienced with libevent...

IMHO it's quite sad that they didn't use ASIO though as it's far more extensive.

That's the thing about reputation though, really easy to burn and really hard to earn back.

I've worked on projects where touching a main header incurred a 1 hour compile even with Incredibuild. You can understand how people can get sensitive with compile times in cases like that.

And interestingly, Chris Kohlhoff (asio author) is currently working on an executors library / c++ standard proposal.

Other question: how would wangle compare to Cap'n Proto (as the post mentions that wangle is an RPC framework, and is zero-copy)

Zero-copy in capnproto docs and in this blog post actually mean different things (the first means that serialized and in-memory representations of capnproto messages are the same and the second means the absence of copying between user space and kernel space when sending a file over the network).

I haven't used the standalone version, but I have used the boost version for build a cross platform RPC library quite intensively. Unfortunately compile times there were really bad, for about 10kLoC C++ I had a compile time of nearly 1 minute (about 5years ago on a medium speed machine back then). I later also built the same library using Qt and the compile times were below 20 seconds. I think the differences came from the fact that asio is heavily templated, you get all in headers and favors directly instantiated objects instead of pointers. In QT you mostly have pointers (and therefore work with forward declarations to the implementations).

Besides that I think asio is a really good library. It gives you LOTS of options how to handle your workload. E.g. much more than libuv, in the sense that you can mix asynchronous and [non-blocking] synchronous IO calls inside your application, do IO calls from different threads, organize work with executors (io_services) and strands, etc. The drawback is that not all of these patters work good, and giving the users this kitchen sink of functionality could lead to worse results than a more focused approach. E.g. it took me a while to realize that calling io_service.run() from multiple threads is not the best idea.

They actually are pulling in boost. System thread and filesystem but not asio, according to the cmake file.

The other commenters are probably right that they wanted to integrate with folly's existing async infrastructure.

Companies tend to stick to their own ecosystems, and in this case Facebook's folly library has already bought into libevent, for better or worse. Hopefully once asio gets standardized more libraries will switch over, but until then there are a number of legitimate issues:

* There's a Boost version and a stand-alone version, you might want to use one but not the other: * Boost requires linking against Boost.System, making it not header-only anymore. * Stand-alone isn't as widely used and if you've already bought into Boost, you might not want an extra dependency.

* Asio's API documentation exists, but that's about the best you can say about it.

* The standard version is likely to resemble the library but won't be quite the same. When it gets standardized, you still have to adapt your code. One might reasonably argue it doesn't matter much whether to use one dependency vs. another if neither binary nor source compatibility can be preserved.

* The Networking TS didn't make the standard for C++17 so it'll still be a long time until the C++ world converges around it.

* Chris Kohlhoff's complete absence from both the Boost and stand-alone GitHub project's issue queues raises questions about the state of maintenance, there are lots of pull requests pending without upstream action. (The one email I sent him regarding his executors proposal also never got a reply.) Modifying their own library would be much easier for Facebook than getting asio patches upstream.

Personally I'd like to see a world where new C++ projects depend on asio, but it's understandable if others feel differently about it.

Reply on news.ycombinator.com