I'll cancel the vote.
On Fri, Sep 5, 2014 at 1:43 PM, Ufuk Celebi <[email protected]> wrote: > OK. Thanks for starting the new thread. > > I would say that we then [CANCEL] the ongoing vote about Scala vs. Java > until the Akka issue is resolved. > > > On Fri, Sep 5, 2014 at 12:54 PM, Stephan Ewen <[email protected]> wrote: > > > Okay, to make things clearer, I will start a separate thread for the > > proposed use of Akka, which talks only about the Akka/RPC question, > because > > things keep getting confused. > > > > Let's postpone this thread (Java vs Scala) until we resolved the Akka > > question first. > > > > > > On Fri, Sep 5, 2014 at 12:10 PM, Till Rohrmann <[email protected]> > > wrote: > > > > > Hi Daniel, > > > > > > the genesis of my proposal was that I resumed Asterios' effort to > > introduce > > > Akka to handle our RPC calls. Asterios idea was to incorporate Akka > into > > > Flink transparently. That meant to use Akka for the MethodInvoker of > the > > > proxies and as the server to handle the calls. While rebasing it on the > > > latest master of Flink I noticed that we left out some potential of > Akka > > by > > > pursuing this approach. Among others, this includes the supervision, > > > monitoring and exception forwarding mechanism. By making the JobManager > > and > > > TaskManager (and possibly other components if it proves worth) actors, > we > > > would get this for free, without having to go through the proxies, > method > > > invoker and call actors. Furthermore, I think that this adds > unnecessary > > > complexity. If we use Akka, why not properly? At this point you are > right > > > that we did not vote on using Akka and I did not think about it. I > > thought > > > that by continuing Asterios work, it would comply with the project. > > > > > > However, making JobManagers and TaskManagers actors comes at the price > of > > > rewriting them, which is unavoidable. Since Akka offers Scala as well > as > > > Java bindings, it would be possible to do it with both. Since Scala > > > supports pattern matching, lambdas and embraces more the functional > > > paradigm, it is in my view better suited for implementing an actor > based > > > RPC system. With Java, the code will become more verbose and probably > not > > > so neat to read. > > > > > > For example, for each message it would be necessary to create a Java > > class > > > with the members, getters and setters whereas in Scala it is most of > the > > > time a one line case class definition. For each call back it would be > > > necessary to implement an interface and overwrite the corresponding > > method > > > whereas for Scala it is just a lambda expression (to be precise an > > > anonymous function). For short call back functions we would have more > > Java > > > boiler plate code than actual function code. > > > > > > In order to distinguish the different messages in Java, one would have > a > > > long list of if(msg instanceof RegisterMessage){} else if (msg > instanceof > > > SubmitTask){}.... and cannot directly access the members of the message > > > classes. In Scala it would be simply a pattern matching. Since both > > > languages are Turing-complete and even run in the same JVM, the > > differences > > > are thus conciseness and expressiveness. But in the end everything can > > also > > > be implemented in Java. > > > > > > There is no functional argument for Scala just the advantages of a > > shorter > > > and probably more readable implementation. Since I will probably > > implement > > > it, I'd opt for the shorter solution and thus I started this vote. But > > > there is no necessity to use Scala here. If we decide for Akka, then > Akka > > > will simply motivate the use of Scala but not enforce it. > > > > > > Best regards, > > > > > > Till > > > > > > > > > On Fri, Sep 5, 2014 at 11:24 AM, Kostas Tzoumas <[email protected]> > > > wrote: > > > > > > > Hi Daniel, > > > > > > > > +1 on the argument about attracting developers being irrelevant, the > > > > argument can work both ways and is very brittle > > > > > > > > The reasons for using Akka as a library (irrespective of the > > programming > > > > language) have been clearly articulated in my opinion by Stephan and > > Till > > > > in this thread. > > > > > > > > The reasons for using the Scala Akka API versus the Java Akka API is > > > simply > > > > ease and speed of development, as Scala is a better language for this > > > task. > > > > Perhaps Till could expand the argumentation a bit more here, but I > > > suspect > > > > that a language with pattern matching is a good fit for message > > > > passing-like systems. > > > > > > > > Kostas > > > > > > > > > > > > > > > > On Fri, Sep 5, 2014 at 12:38 AM, Ufuk Celebi <[email protected]> wrote: > > > > > > > > > Hey Daniel, > > > > > > > > > > On Thu, Sep 4, 2014 at 11:36 PM, Daniel Warneke < > [email protected]> > > > > > wrote: > > > > > > > > > > > I agree that the questions “akka” and “Scala” should be treated > > > > > > separately. Unfortunately, this is not how the discussion has > been > > > led > > > > so > > > > > > far. Instead, the new akka RPC service is used to motivate the > > > > necessity > > > > > > for Scala in the runtime core. I still don’t see that necessity. > I > > > > tried > > > > > to > > > > > > find the implementation of the new akka RPC service on github. > The > > > only > > > > > > code I found was from Asterios, but it looks like he was > perfectly > > > able > > > > > to > > > > > > encapsulate the whole akka RPC thing in 5 Java classes [1]. > > > > > > > > > > > > > > > > I don't think that anybody is talking about the necessity of Scala. > > > Yes, > > > > > Akka and an actor based refactoring of core runtime parts result > in a > > > > hard > > > > > dependency to Scala for the core (because Akka is written in > Scala), > > > but > > > > it > > > > > does *not* necessitate to do the refactoring itself in Scala, > because > > > > there > > > > > is an Akka Java API as well. > > > > > > > > > > Are you concerned with the dependency to Scala or with using Akka's > > > Scala > > > > > API? > > > > > > > > > > I think that Till started this thread and the [VOTE] exactly > because > > he > > > > is > > > > > well aware that it is *not* necessary to do it in Scala. He sees > good > > > > > reasons to do it in Scala and asks the community to vote on it. > > Again, > > > > > because he is aware that this is not a small or light weight > change. > > > > > > > > > > The second argument (Scala will attract new developers to the > > project) > > > is > > > > > > nothing but speculation. This might as well totally backfire and > > lead > > > > to > > > > > > the opposite. > > > > > > > > > > > > > > > > I agree that this point is speculative and both outlined outcomes > > > > (attract > > > > > or repel developers) are possible. But it is also not the only > > argument > > > > > that has been raised in favor of Scala. Other more technical (not > > > > > speculative) points have been given. It is the goal of the vote to > > > find a > > > > > consensus about whether these points are sufficient or not. > > > > > > > > > > > > > > > > The only explanation I have for this push towards akka and Scala > is > > > > that > > > > > > there are already plans to expand the usage of akka way beyond > pure > > > > RPC. > > > > > In > > > > > > this case, I feel these plans should be clearly articulated on > the > > > dev > > > > > > list. A simple RPC service does not justify the proposed changes > in > > > my > > > > > > opinion. > > > > > > > > > > > > > > > > There is no push for Scala. It's a vote. And the reasons for going > > for > > > > Akka > > > > > have been repeated a few times by now. > > > > > > > > > > I think the way that Asterios initially introduced Akka beneath the > > > > > existing RPC proxy service (independently of whether he did in > Scala > > or > > > > > Java) would not allow us to make use of central features of Akka > > (some > > > of > > > > > which Till and Stephan outlined). > > > > > > > > > > Best wishes, > > > > > > > > > > Ufuk > > > > > > > > > > > > > > >
