Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wangle – an asynchronous C++ networking and RPC library

code.facebook.com

Post reply on HN
Print view View original

61–70 of 78 posts

Re: Wangle – an asynchronous C++ networking and RPC library

#61

Post by sreque »

thepumpkin1979 wrote: post #8

I just tried to compile folly in OSX and it fails to compile with homebrew. https://github.com/facebook/folly/issues/400 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 i…

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.

Re: Wangle – an asynchronous C++ networking and RPC library

#62

Post by chetanahuja »

"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.

Re: Wangle – an asynchronous C++ networking and RPC library

#63

Post by jpetso »

je42 wrote: post #7

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

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.

Re: Wangle – an asynchronous C++ networking and RPC library

#64

Post by chetanahuja »

pjmlp wrote: post #52
rburhum wrote: post #41

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…

"Also Windows Phone is the only mobile OS where C++ is a first class language."

Umm... I don't know how you define "first class language" but our SDK (networking stack) compiles C++ code right in the same XCode project with ObjC code without any sort of translation layers etc (a la JNI in Java) between the two.

Re: Wangle – an asynchronous C++ networking and RPC library

#65

Post by pjmlp »

chetanahuja wrote: post #64
pjmlp wrote: post #52

Earlier quoted context omitted.

> 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…

"Also Windows Phone is the only mobile OS where C++ is a first class language." Umm... I don't know how you define "first class language" but our SDK (networking stack) compiles C++ code right in the same XCode project with ObjC code without any sort of translation layers etc (a la JNI in Java) between the two.

iOS doesn't expose the majority of its APIs as a C++ APIs, they are either plain C, or Objective-C.

The SDK you mention is a code example, that is the only support iOS offers for C++, meaning infrastructure code with little interaction to the whole iOS stack.

If I am not mistaken (no iOS dev), besides the IO Kit and Metal shaders, there isn't much more in terms of C++ APIs in iOS.

You have to wrap calls to Objective-C via Objective-C++, for a full stack app. With Swift slowly taking the place of Objective-C, this will be even harder.

Whereas WP offers the so called projections as C++/CX (similar to using Objective-C++ in concept), C++ with the WRL template library, or plain modern C++.

All of those projections offer 100% of WP APIs as C++ APIs.

Although actually the majority of WP developers just makes use of C# alongside C++.

Re: Wangle – an asynchronous C++ networking and RPC library

#66

Post by ausjke »

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.

Failed to compile with CMake 2.8

    CMake Error at /usr/share/cmake-2.8/Modules FindPackageHandleStandardArgs.cmake:91 (MESSAGE):
    REQUIRED_ARGS (missing: FOLLY_INCLUDE_DIR  OLLY_LIBRARIES)
    Call Stack (most recent call first):
   /usr/share/cmake-2.8/Module/FindPackageHandleStandardArgs.cmake:252(_FPHSA_FAILURE_MESSAGE)
   cmake/FindFolly.cmake:23 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
   CMakeLists.txt:17 (find_package)

Re: Wangle – an asynchronous C++ networking and RPC library

#67

Post by rburhum »

pjmlp wrote: post #65
chetanahuja wrote: post #64

Earlier quoted context omitted.

"Also Windows Phone is the only mobile OS where C++ is a first class language." Umm... I don't know how you define "first class language" but our SDK (networking stack) compiles C++ code right in the same XCode project with ObjC code without any sort of translation layers etc (a la JNI in Java) between the two.

iOS doesn't expose the majority of its APIs as a C++ APIs, they are either plain C, or Objective-C. The SDK you mention is a code example, that is the only support iOS offers for C++, meaning infrastructure code with little interaction to the whole iOS stack. If I am not mistaken (no iOS dev), besides the IO Kit and Metal shaders, there isn't much more in terms of C++ APIs in iOS. You have to wrap calls to Objective-…

Although I agree with most of the comments you said, I have to strongly disagree with "First class C++ support of Windows Mobile" when compared to iOS (or even Android). I have an entire non trial stack of C/C++ libraries that I use which I easily bring to Android and iOS using a cross-compiling build system we wrote (https://github.com/amigocloud/amigomake). The C/C++ dependencies include :

Freetype v. 2.4.10, OpenSSL v. 1.0.1m, Bzip v. 1.0.6, libidn v. 1.24, GEOS v. 3.4.2, CURL v. 7.39.0, Proj4 v. 4.8.0, SQLite v. 3080700, Jpeg v. 8d, PNG v. 1.2.50, Minizip v. 11. uuid, libwebsockets, rapidjson, Spatialite, Coffeecatch, tinydir, Freetype-GL, libtess2, RTree, Spline, SHA, lodePNG.

and are used by this cross-platform mobile app: https://github.com/amigocloud/amigoclient

Getting this libraries to work on *nix platforms (e.g. Android or iOS) is easy. Getting them to work on Windows Mobile is a nightmare - starting with the fact that they don't even support things like OpenGL...

Re: Wangle – an asynchronous C++ networking and RPC library

#68

Post by kinofcain »

vvanders wrote: post #24
je42 wrote: post #7

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.

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.

Re: Wangle – an asynchronous C++ networking and RPC library

#69

Post by pjmlp »

rburhum wrote: post #67
pjmlp wrote: post #65

Earlier quoted context omitted.

iOS doesn't expose the majority of its APIs as a C++ APIs, they are either plain C, or Objective-C. The SDK you mention is a code example, that is the only support iOS offers for C++, meaning infrastructure code with little interaction to the whole iOS stack. If I am not mistaken (no iOS dev), besides the IO Kit and Metal shaders, there isn't much more in terms of C++ APIs in iOS. You have to wrap calls to Objective-…

Although I agree with most of the comments you said, I have to strongly disagree with "First class C++ support of Windows Mobile" when compared to iOS (or even Android). I have an entire non trial stack of C/C++ libraries that I use which I easily bring to Android and iOS using a cross-compiling build system we wrote ( https://github.com/amigocloud/amigomake ). The C/C++ dependencies include : Freetype v. 2.4.10, Ope…

Those C and C++ dependencies are using OS specific APIs.

The developers not caring about writing portable code doesn't make it less first class on Windows Phone.

I don't see any chapter on ANSI C or ANSI C++ standards about OpenGL.

When I learned C and C++, targeting UNIX only didn't meant much, because POSIX wasn't the same thing across all UNIX systems and Windows wasn't the only non-POSIX OS.

So we learned to abstract the OS APIs properly.

Nowadays it seems we are reaching a UNIX mono-culture.

Post reply on HN