I have used this library pretty heavily in some of my recent work and I love how easy it makes building performant async network servers in C++.
Minor nitpick: It would be nice though, if they built shared libraries by default though, last release I took I had to tell cmake to make a shared library. Since this is used by fbthrift as a dependency, I think it really makes sense to build it that way by default. I also use fblualib and it builds with a very old version of some of these libraries probably because the FAIR team didn't want to mess with tweaking the builds so they can work with standalone wangle (parts of the library used to be part of folly).
After most compilers started properly supporting the newer C++ standards, it seems there has been an increase in the amount of love that C++ libraries are getting. A lot of people like the to say that [x] is superior to C or C++ - often ignoring that their favorite language's libraries/runtime/compilers/vm is most likely implemented in the very same languages they are putting down.
> After most compilers started properly supporting the newer C++ standards, it seems there has been an increase in the amount of love that C++ libraries are getting.
Sadly there are many more compilers out there than just gcc, clang, icc and msvc++.
Many of those aren't still C++11 compliant, specially in mainframes, classical commercial UNIXes, embedded real time OS and certified compilers.
But it is true, thanks to the productivity of latest standards, there has been an increase in C++ visibility, specially thanks to Microsoft.
People like to bash their C++'s compliance, but they are the commercial vendor with the more up to date support, even than icc last time I checked.
Also they were the main sponsors for Back to native conferences and eventually making it together with CppCon.
Also Windows Phone is the only mobile OS where C++ is a first class language.
>. A lot of people like the to say that [x] is superior to C or C++ - often ignoring that their favorite language's libraries/runtime/compilers/vm is most likely implemented in the very same languages they are putting down.
A lot of people like to point out that fact, ignoring that many compiler writers tend to use C or C++ out of convenience for existing tools instead of bootraping the full eco-system around a new programming language.
Many use the same route as Go, using one of those languages and when the toolchain gets mature, those parts get re-writen.
All in all, I do like the language, now if we could get rid of those C underpinnings...
> often ignoring that their favorite language's libraries/runtime/compilers/vm is most likely implemented in the very same languages they are putting down
I don't see how that's an argument against a language being "superior to C or C++". You can't create a self-hosting compiler for your language without having already created a non-self-hosting compiler for your language. That means every language is going to have to be "bootstrapped" in terms of something else first. C is the usual candidate just because there are a plethora of useful compiler/runtime/vm-ish libraries people like to rely on for "language prototyping" that expose C bindings—and there are very few other languages than C/C++ that have zero-overhead, zero-friction C binding support.
Rust is one of those languages—and it does indeed look like things are going in the direction of new languages getting prototyped/bootstrapped with a Rust compiler/runtime/vm instead.
Also, Once I manage to compile folly and then wangle, what kind of database drivers can I use in conjunction with this? Would I shoot myself in the foot if I use this with libpq under CPUThreadPoolExecutor?
Same with Rust and dlang, I'm not sure how to apply the freedom to have pluggable executor into something useful in real life, I think this is the main reason Golang is killing it and it keeps getting better.
The problem is the exact opposite. The question you should be asking, is: how can I use my go code in Rust/D/C++? The answer is, not very easy, given that go's runtime is largely incompatible with C.
At least with C++, you can easily write C shim layers and your code becomes compatible with most runtimes in existence. The opposite is not true with Go.
Go uses synchronous I/O backed with an M:N implementation. Rust and D use synchronous I/O backed with a 1:1 implementation. Semantically, there is no difference between the two. The difference is in the implementation, and 1:1 threading is not as slow as you think on Linux.
> what kind of database drivers can I use in conjunction with this?
Usually synchronous database drivers have to be reimplemented in an asynchronous fashion to work with event loops. It's not very hard though, could be as simple as adding jump tables and context structures into synchronous functions.
Emulating asynchronous execution with a thread is ok too. You do that to access filesystem anyway.
But if your first thought is about accessing a database server - you probably don't need to go asynchronous at all.
The first thing that comes to mind after reading this is GRPC (https://github.com/grpc/grpc). That library has the advantage of supporting just about every language, not just C++.
Good to see C++ is gaining more visibilities these days, considering the Oracle/Java combination I hope C++ can take away some JAVA dominance, at least nobody is going to sue you over C++ APIs.
When I name things I look for a word that doesn't get drowned out by unrelated hits in search engines, and has some kind of link to what the library does. Straightforward names are great when they are obvious, easy to remember, and not a search disaster. Otherwise clever memorable names make a pretty good substitute.
I picked the name Wangle because it is a synonym to Finagle, and because I couldn't think of a simple self-descriptive name. I think I also had the Edward Lear poem in the back of my subconscious.
We don't have a central naming authority - people just name their projects whatever they want. Sometimes we have to or want to rename things for various reasons but it's mostly similar to the open source world.
"Folly" is a relatively common English word. "Wangle" is less common but I still see it from time to time.
What I find more interesting than the naming is FB's willingness to remove features from Folly as they are made redundant by Boost or std. I'm unaccustomed to such a lack of arrogance from a major player.
I was going to correct you and say you meant "wrangle". Turns out they can have the same meaning! Wonder if there are other examples of two words being one letter off that mean the same thing.
"folly" is a play on Facebook Open-source LibrarY.
I think using uncommon English words helps with searchability, although of course is not as good as made-up words or acronyms.
Also, check out crossbar.io and the WAMP protocol, offering transparent, clean and yet simple PUB/SUB & RPC accross languages, including C++, Python, PHP and JS (node and yes, browsers).
WAMP is a protocol, Wangle is a framework that you can use to implement protocols (like WAMP), crossbar is a broker (an application that implements the protocol using a [python] framework. So it's not a direct comparison.
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.
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.
"Wangle is heavily influenced by the JVM-based libraries Netty,"
Stopped reading there. Have experience with using Netty in a java server application and engineers dread being assigned a bug or enhancement in that codebase. There's a tendency throw around the word "over-engineered" lightly but netty is a real, live and inexplicably popular example of exactly what that word means.
I can't speak for Wangle, but I've used Google's version (GRPC) to implement the networking transport for an N64 netplay hack[1] I wrote, and it was awesome.
[+] [-] jhartmann|10 years ago|reply
[+] [-] rburhum|10 years ago|reply
[+] [-] pjmlp|10 years ago|reply
Many of those aren't still C++11 compliant, specially in mainframes, classical commercial UNIXes, embedded real time OS and certified compilers.
But it is true, thanks to the productivity of latest standards, there has been an increase in C++ visibility, specially thanks to Microsoft.
People like to bash their C++'s compliance, but they are the commercial vendor with the more up to date support, even than icc last time I checked.
Also they were the main sponsors for Back to native conferences and eventually making it together with CppCon.
https://blogs.msdn.microsoft.com/vcblog/2014/04/03/cppcon-th...
Also Windows Phone is the only mobile OS where C++ is a first class language.
>. A lot of people like the to say that [x] is superior to C or C++ - often ignoring that their favorite language's libraries/runtime/compilers/vm is most likely implemented in the very same languages they are putting down.
A lot of people like to point out that fact, ignoring that many compiler writers tend to use C or C++ out of convenience for existing tools instead of bootraping the full eco-system around a new programming language.
Many use the same route as Go, using one of those languages and when the toolchain gets mature, those parts get re-writen.
All in all, I do like the language, now if we could get rid of those C underpinnings...
[+] [-] derefr|10 years ago|reply
I don't see how that's an argument against a language being "superior to C or C++". You can't create a self-hosting compiler for your language without having already created a non-self-hosting compiler for your language. That means every language is going to have to be "bootstrapped" in terms of something else first. C is the usual candidate just because there are a plethora of useful compiler/runtime/vm-ish libraries people like to rely on for "language prototyping" that expose C bindings—and there are very few other languages than C/C++ that have zero-overhead, zero-friction C binding support.
Rust is one of those languages—and it does indeed look like things are going in the direction of new languages getting prototyped/bootstrapped with a Rust compiler/runtime/vm instead.
[+] [-] thepumpkin1979|10 years ago|reply
Also, Once I manage to compile folly and then wangle, what kind of database drivers can I use in conjunction with this? Would I shoot myself in the foot if I use this with libpq under CPUThreadPoolExecutor?
Same with Rust and dlang, I'm not sure how to apply the freedom to have pluggable executor into something useful in real life, I think this is the main reason Golang is killing it and it keeps getting better.
For now I have my money on Go but can't wait for http://www.ponylang.org/ to become stable.
Edit: Issue reported has been closed, I can now proceed to install wangle https://github.com/facebook/folly/issues/400
Edit 2: Found another issue, this time installing wangle https://github.com/facebook/wangle/issues/37
[+] [-] sreque|10 years ago|reply
At least with C++, you can easily write C shim layers and your code becomes compatible with most runtimes in existence. The opposite is not true with Go.
[+] [-] pcwalton|10 years ago|reply
[+] [-] zzzcpan|10 years ago|reply
Usually synchronous database drivers have to be reimplemented in an asynchronous fashion to work with event loops. It's not very hard though, could be as simple as adding jump tables and context structures into synchronous functions.
Emulating asynchronous execution with a thread is ok too. You do that to access filesystem anyway.
But if your first thought is about accessing a database server - you probably don't need to go asynchronous at all.
[+] [-] jfasi|10 years ago|reply
[+] [-] ausjke|10 years ago|reply
Failed to compile with CMake 2.8
[+] [-] educar|10 years ago|reply
Does anyone know where facebook is coming up with all these words - folly/wangle?
[+] [-] fugalh|10 years ago|reply
I picked the name Wangle because it is a synonym to Finagle, and because I couldn't think of a simple self-descriptive name. I think I also had the Edward Lear poem in the back of my subconscious.
We don't have a central naming authority - people just name their projects whatever they want. Sometimes we have to or want to rename things for various reasons but it's mostly similar to the open source world.
[+] [-] cgh|10 years ago|reply
What I find more interesting than the naming is FB's willingness to remove features from Folly as they are made redundant by Boost or std. I'm unaccustomed to such a lack of arrogance from a major player.
[+] [-] riyadparvez|10 years ago|reply
[+] [-] DougN7|10 years ago|reply
[+] [-] ot|10 years ago|reply
[+] [-] floatboth|10 years ago|reply
There are many meanings, including:
> A combination of the words wang + angle. > Noun: A curved/bent/crooked penis.
[+] [-] 420TOKER|10 years ago|reply
[+] [-] vardump|10 years ago|reply
What transport layers are supported and can it be extended?
What I can gather, it only supports IPv4/IPv6 TCP or UDP transports. TLS is also supported.
Notably, local pipes seem to be unsupported. Those can be sometimes useful for performance and security/isolation reasons.
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] sametmax|10 years ago|reply
[+] [-] Matthias247|10 years ago|reply
[+] [-] je42|10 years ago|reply
[+] [-] vvanders|10 years ago|reply
[+] [-] jpetso|10 years ago|reply
* 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.
[+] [-] chetanahuja|10 years ago|reply
Stopped reading there. Have experience with using Netty in a java server application and engineers dread being assigned a bug or enhancement in that codebase. There's a tendency throw around the word "over-engineered" lightly but netty is a real, live and inexplicably popular example of exactly what that word means.
[+] [-] euyyn|10 years ago|reply
[+] [-] averageJoeCoder|10 years ago|reply
[+] [-] ec109685|10 years ago|reply
[+] [-] soconfused1|10 years ago|reply
[+] [-] jfasi|10 years ago|reply
[1]: https://github.com/water-works
[+] [-] eva1984|10 years ago|reply
[+] [-] x5n1|10 years ago|reply
[+] [-] tveita|10 years ago|reply
Writing a networking library in Go does nothing for Facebook if their services are written in C++.
[+] [-] thrownaway2424|10 years ago|reply
[+] [-] swah|10 years ago|reply