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 >
