fugalh

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.

Indeed, any good intro to Rx points this out: Observable is the plural of future/promise.

When people are trying to do fancy streaming stuff with futures and come to me for help, I generally recommend they do the streaming with Rx instead. (eg rxcpp from Microsoft)

Yes, templates are expensive at compile time (memory and time both). folly/futures only depends on a few pieces of folly/, you may find that you can use the futures headers just fine. If building libfolly is the showstopper, you might be able to comment out all the non-dependent files.

Scala also takes the same way C++11 does, and to my mind it makes more sense this way. So from my perspective Javascript is the backward duck here. I agree it would be nice if we could all just settle on something

Yes, the two terms are unfortunately both synonymous (comparing different implementations of the pattern in different languages), and usually have specific meanings in the context of any given implementation. Often, as here, Promise is the write handle and Future is the read handle.

It is along the same lines as boost's futures implementation. We have a different mechanism for expressing thread management, born out of trial and error and Facebook engineer feedback. At the time we set out to write this boost futures were slow and buggy (1.53), and C++ standard monadic futures proposals were in very early stages (it now appears that there will be monadic futures in C++17). I do not know if boost futures are now more robust and/or more performant in 1.58.