5 ms·

From what I can tell, this is a production-ready differential dataflow solution with basically, a DSL. Is Java supposed to be the selling point as in, "oh it's

From what I can tell, this is a production-ready differential dataflow solution with basically, a DSL. Is Java supposed to be the selling point as in, "oh it's just Java so you can run it on your Java things?" Why not just make it some GRPC-thing with SDKs or even its own well-documented DSL?

nathanmarz 3y ago
It can be programmed with any JVM language, such as Clojure, Scala, or Kotlin. The JVM is a well-understood and widely used platform, which is why Rama is built on top of it. Being a library in a general purpose language as opposed to a custom language means you can do things like: generate dataflow code dynamically, easily use any JVM library, easily integrate with other external systems (e.g. databases) using their Java client, and easily mix regular Java code with Rama dataflow code. All of these are extremely important and should never be sacrificed. Losing any one of these massively increases complexity. Our Mastodon implementation relies heavily on being able to do these things.
- npace12 3y ago
  Yes, I get that, and it makes sense. But given that this is a potentially very powerful, (but closed) platform, I see the JVM part as an implementation detail. If I'm going to be getting my whole team writing pstates and things, now I also have to tell them they need to write their code for the JVM. Temporal.io made a platform and wrote it in Go or whatever they use, but they released with a few SDKs for different languages. Would this just not be possible with Rama? like, does a serializing interface like grpc make Rama somehow not worth it?
  - nathanmarz 3y ago
    One way to think of Rama is as a "programmable datastore", where your application logic goes into and is colocated with your data storage. So your logic has to be written to run on the same platform on which Rama is built, which is the JVM.

nathanmarz 3y ago

It can be programmed with any JVM language, such as Clojure, Scala, or Kotlin. The JVM is a well-understood and widely used platform, which is why Rama is built on top of it. Being a library in a general purpose language as opposed to a custom language means you can do things like: generate dataflow code dynamically, easily use any JVM library, easily integrate with other external systems (e.g. databases) using their Java client, and easily mix regular Java code with Rama dataflow code. All of these are extremely important and should never be sacrificed. Losing any one of these massively increases complexity. Our Mastodon implementation relies heavily on being able to do these things.

npace12 3y ago
Yes, I get that, and it makes sense. But given that this is a potentially very powerful, (but closed) platform, I see the JVM part as an implementation detail. If I'm going to be getting my whole team writing pstates and things, now I also have to tell them they need to write their code for the JVM. Temporal.io made a platform and wrote it in Go or whatever they use, but they released with a few SDKs for different languages. Would this just not be possible with Rama? like, does a serializing interface like grpc make Rama somehow not worth it?
- nathanmarz 3y ago
  One way to think of Rama is as a "programmable datastore", where your application logic goes into and is colocated with your data storage. So your logic has to be written to run on the same platform on which Rama is built, which is the JVM.