It's funny because the article's only mention of java is "Wallaroo isn’t built on the JVM, which provides advantages that we will cover in a later blog post."
Quickly followed by pointless Factory classes and classes implementing an interface with one method.
I guess the reason is that classes are picklable and functions, by default, are not? This is supposed to be a distributed system after all.
If you'd be interested in playing with Wallaroo and providing feedback on a 2nd generation of the API, feel free to reach out via our IRC channel, user mailing list or ping me via my personal email address that is in my HN profile.
We are looking for folks to help drive the next version of the API. The first one was done with feedback from a couple of clients who were interested in using Python and in many ways reflects their tastes. Feedback from a wider range of Python users is something we are actively soliciting at this point.
Having to create a class called xPartitionFunction doesn't seem to favour easy pickability. Why isn't it just a function/callable?
Likewise builder, just ask for a callable, and the smallest "builder" is the state class itself.
Computations seem similar, the APIDoc states they must provide a compute() method but the example shows only a compute_multi. Is there a use case for having both on the same object? If there isn't, just ask for a reduction function and provide a decorator for one of the use case. Or don't and always ask for a list of results.
Or handle the "multi" case via a generator I guess (call reducer, if it returns a generator run it and add all items to the processing queue, otherwise add the one item).
Quickly followed by pointless Factory classes and classes implementing an interface with one method.
I guess the reason is that classes are picklable and functions, by default, are not? This is supposed to be a distributed system after all.