Stephan,
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].
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.
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.
Best regards,
Daniel
[1]
https://github.com/asteriosk/stratosphere/tree/akka_rpc/stratosphere-runtime/src/main/java/eu/stratosphere/nephele/ipc
Am 04.09.2014 12:00, schrieb Stephan Ewen:
Again, Java vs. Scala is a different question than akka or no akka.
Java vs Scala is in the end a question of ease of use, and of adding a
stronger Scala side to the project (for our own sake or for attracting
interested developers).
Akka is planned not simply as an rpc replacement alone, but for remote
calls, asynchronous callbacks, failure detection, master failover, and a
simpler concurrency model in the execution graph.
I Actually think that the current rpc is limiting us, for example because
of the lack of callback support, which makes the polling parts necessary.
Stephan
