On October 11, 2013, we lauched the second Akka survey—the first one was executed three years ago before the release of Akka 1.0. We are very happy to report that 315 of you took the time to fill out the two page questionaire, and we are even more happy about some nice free-form praise within those. But I’m getting ahead of myself, so let’s start at the beginning.
The first surprise is that nine out of ten respondents use the Scala API, but only one in six uses Java. One reason for this might be that the channels through which we advertised the survey favor our Scala audience, or it might be that Akka is a factor in inspiring a switch of language choice as well—which we know anecdotal evidence for. Be that as it may, we will continue to treat Java as a first class citizen, even more so in the light of Java 8 and its lambda support which will enable us to bring the two APIs closer together next year. This will allow us to bring Akka’s goodness to an even wider circle of developers and is consequently one of our current priorities and appears on our updated road map (see below).
On the second question it is no surprise that almost everyone uses the Actor module, but we were a bit surprised that only half confess their use of TestKit—it seems that many of you have been naughty! There are a handful of mentions that testing can be improved, but it seems not to be prohibitively difficult, so we can only recommend everyone to check it out (docs for Java and Scala). Looking further down the list of modules SLF4J, Remote and Cluster form the next tier with roughly 40% usage. Between 20% and 10% we can then find the Microkernel, Agents and Camel, which is not surprising for somewhat specific infrastructure pieces. The other modules then range closely, with the File-based Mailbox being last at 1%. I was of course personally pleased to see that 8% checked the box next to Typed Channels and that FSM received several dedicated mentions. A few people are already actively using our upcoming event-sourcing support (the Persistence module). The support for durable mailboxes will be phased out gradually once the persistence module is fully available and supported, likewise our dataflow module will be replaced by Scala Async, and in the long-term future we might also drop the Transactor module because because STM is not well-suited for a clustered environment.
The overwhelming majority sees their primary reason for choosing Akka in “safe concurrency” which is a beautiful testament to the quality of our support for this concern. The second place goes to “supervisor hierarchies”—which I’d dub “principled fault handling” now—followed by “scalability by configuration” and “performance” which are tied for third. Only one in six respondents picked “clustering” as one of their top two benefits, which also is not very surprising given that Akka Cluster only recently left the experimental stage and that the aforementioned benefits can be pushed pretty far on a single machine these days.
Now we are getting to the most interesting part: what do you—our dear users—want to see improved? The foremost concern is type safety, and as you know it is one which we share. Typed channels are an experiment which was only partially successful: the implementation relies upon an experimental feature of Scala for which there is no correspondence in Java and other languages and its use feels a bit clunky. The good news is that we have some very promising ideas on how to address this in a way which does not have these issues, but the bad news is that this will necessarily and significantly break source compatibility with Akka 2, so we will have to call it Akka 3. We will start researching and exploring the solution space in a few months, but as this is a field of active academic research we will in parallel continue to support Akka 2 for the foreseeable future and work on it as outlined in the roadmap.
Not far behind on a close second place comes the concern of “guaranteed message delivery”, and we are already working on that in the form of the Akka Persistence module, which gives actors the ability to persist and if necessary replay messages, ensuring at-least-once delivery semantics. From there exactly-once delivery can be implemented on top. The third place—“samples & tutorials”—is something we take very seriously. We have already begun to convert our akka-samples projects into Activator templates, improving and enriching them in the process, and we will add more tutorials before Akka 2.3 comes out. This is important enough to be featured on the roadmap.
The next tier of requested improvements is made up from “cloud deployment”, “performance”, “larger cluster” and “documentation”, and you have seen our progress about how to quickly start large clusters last week. One interesting result is that “enterprise integration” was important for 11% while OSGi ranks last with 4%, but that will not prevent us from fixing deficiencies in our OSGi support before 2.3 is due. The list of other items mentioned contains several interesting points, of which “API stability” is mentioned twice; on other questions it came up that we should be careful with extending Akka further. We see this as a sign that the Akka community is beginning to mature as well and will factor that into future decisions.
When it comes to the the biggest difficulties users have when learning Akka, it was good to see that immutability of messages is not one. The top tier mentioned here consists of “use blocking resources”, “splitting the problem into actors” and “flow control, back-pressure”. The first one will best be countered by having better tutorials available showing for example how to use DB connection pools in an actor-based application, while the second one is explicitly treated in my part of the Coursera course “Principles of Reactive Programming.” For the third problem we are experimenting with first-class stream support including back-pressure, stay tuned! One very good suggestion which came out of this question was to generate a sitemap so that Google finds the docs of the latest stable release before the nightly snapshots.
We promised not to leak the information entered on the second page of the questionnaire, but in anonymous form we would like to mention that five out of six respondents use Akka at their day job and that three quarters have it running in production, which is a very good sign. And while the U.S. contributes the largest subsample, people from all over the world have filled out the survey.
You can see all the gory details in this PDF document and the current roadmap can be found here as usual. Lastly, a big thank you to all who submitted directional advice via the survey. Your responses are very valuable in helping us carve out future roadmap plans. If you have specific questions about the survey, please feel free to reach out to the Akka Team at Typesafe.
