31–40 of 60 posts
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(...) }
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(...) }
- It's hard to figure out what the dependency graph looks like just from promises
- That pattern is verbose and results in gross types when you do it in Java
- With this library, you can easily profile parts of the algorithm to see what's going slow, what's taking a bunch of memory, etc.
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(...) }
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(...) }
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(...) }
The "simple promises" from JS are (somewhat crippled) copies of Futures from other languages. In Scala the results of those futures can be produced at the same time, even if they are purely computational as Scala and most other languages are both asynchronous AND concurrent.
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(...) }
The "simple promises" from JS are (somewhat crippled) copies of Futures from other languages. In Scala the results of those futures can be produced at the same time, even if they are purely computational as Scala and most other languages are both asynchronous AND concurrent.
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(...) }
So, between the lines - Twitter looks ahead to move to Java 8 and finally ditch Scala?
Hum .. don't think so. Not quite yet at least. Underneath this, there is Finagle on top of which most services at Twitter is built on. It offers a java API, but remains a Scala library. And there's still a lot of existing code inside to twitter to ditch Scala right away. Java 8 is awesome, but Java is still not an FP language.
I think the best way to upgrade your java codebase is Kotlin. On the server side, Kotlin +vertx is extremely compelling.. on the Android side, Kotlin pretty much kills it.
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(...) }
Looks just like that. As dstaten said, "just Promise.all but for microservices". I've been contributing to an open-source project called snappi.io - a microservice blueprint that includes very comparable dynamic RPC functionality. Combining RPC with standardized service contracts allows us to create and inject stubs for distributed systems as they get shipped out to solve the problems described in the article. Happy…
Earlier quoted context omitted.
Hum .. don't think so. Not quite yet at least. Underneath this, there is Finagle on top of which most services at Twitter is built on. It offers a java API, but remains a Scala library. And there's still a lot of existing code inside to twitter to ditch Scala right away. Java 8 is awesome, but Java is still not an FP language.
IMHO the problem with Java 8 is not the language but framework support. Except SparkJava, most other frameworks use Java 8 as a "upgraded java compiler". Tge canonical way to write code is still Java 6. I think the best way to upgrade your java codebase is Kotlin. On the server side, Kotlin +vertx is extremely compelling.. on the Android side, Kotlin pretty much kills it.