Maybe I'm missing something, how is this better than simple promises in JS? This seem easy to reason about:
serviceA { Promise.All(b,c).then(...) }
serviceB { (d).then(...) }
serviceC { Promise.All(d,e).then(...) }
Simplify Service Dependencies with Nodes
21–30 of 60 posts
Re: Simplify Service Dependencies with Nodes
#22Please don't ask me why, but I'm going to go out on a limb and guess that one of the people who "invented" this system at Twitter is a Xoogler.
Yup, sure does look awfully familiar....
Re: Simplify Service Dependencies with Nodes
#23Please don't ask me why, but I'm going to go out on a limb and guess that one of the people who "invented" this system at Twitter is a Xoogler.
Looks like just one, from the list of major contributors.
But, Google really has no right to whine about this. They make an explicit tradeoff: they manage to stay 3-5 years ahead of the curve of everyone else by not open sourcing their impressive libraries and infrastructure. But the corollary of that is that there's no place to whine "we got there first!" when someone else produces an implementation of X.
Re: Simplify Service Dependencies with Nodes
#24Please don't ask me why, but I'm going to go out on a limb and guess that one of the people who "invented" this system at Twitter is a Xoogler.
Actually I wrote the first version of this graph library 3yrs ago. It was to help the search relevance team create reusable components, turn implicit dependency management into a first class citizen and finally add a way to dump the graph state at runtime or statically.
Re: Simplify Service Dependencies with Nodes
#25Seems like all the languages and frameworks are creeping slowly and cautiously towards the Actor model. Come on in folks, the water's fine!
Re: Simplify Service Dependencies with Nodes
#26Please don't ask me why, but I'm going to go out on a limb and guess that one of the people who "invented" this system at Twitter is a Xoogler.
Well producers are available in Dagger now https://google.github.io/dagger/producers.html
Re: Simplify Service Dependencies with Nodes
#27[deleted]
Re: Simplify Service Dependencies with Nodes
#28From the article..
> Nonetheless, Finagle still solved a huge problem for us as we now have real data dependencies and a more efficient execution engine. We gradually converted the Blender workflow code from batch style to Future style in 2013. It ran faster, the code became less error-prone but the readability was still not perfect. It was hard to follow, a pain to debug, tricky to test, and there were lots of duplicate function names.
from the git repo for Node...
> However, this library was written in Scala and isn't exactly Java friendly. It naturally involves a lot of callbacks and repeated function signatures. When it comes to waiting on multiple Futures, the code gets ugly very fast. Nodes is a Java library that aims to solve these problems, making the asynchronous code easier to read, to maintain and to test in Java.
what are they suggesting ? use Finagle for Scala and Nodes for java based projects?
Re: Simplify Service Dependencies with Nodes
#29Seems like all the languages and frameworks are creeping slowly and cautiously towards the Actor model. Come on in folks, the water's fine!
[deleted]
Re: Simplify Service Dependencies with Nodes
#30So, between the lines - Twitter looks ahead to move to Java 8 and finally ditch Scala?
Why ditch Scala completely?
I'm also curious about this one — I always found Scala to be a pretty messy language to write (the code starts elegant, but gets convoluted pretty fast), but I'd love to hear how insiders are thinking about it.