First Piece with Akka 2.0
Doing it with Java for now. I can see some good things in Scala, but I find the language feature rich and readability poor. The last, stupidest, most ridiculous reason to consider a new language is to decrease typing, so that‘s not a remote consideration. Frankly, it‘s the shorthand stuff in Scala that seems the most hopelessly adolescent. That said, I may come around, who knows. People flamed me for saying Objective-C was my choice for most readable language, but I stand by that and I will take Java and/or C++ after that (yes, the latter can be super obfuscated if used badly, like all languages).
Before I talk about what I like about Akka, here‘s a tiny bit of history. EJB 1.0, one of the most boneheaded component specs in the history of the world, left async considerations completely off the menu. The subsequent uproar led to the release of EJB 2, which added little more than message-driven beans, with their one method interface: onMessage. I did a large project using 2.x where we did some cool stuff, with a queue-backed by JMS. Of course, think about the prospect of setting up such a contraption on your local machine? Doesn‘t sound good does it? And then there‘s the question of testing it. Oh, and let‘s not forget that JMS implementations sucked for a really long time, then there was the period of JMS hype with hypesters like Sonic trying to convince people that their implementation was so great, it was like being born to MoM all over again. Then after all that time, doesn‘t really seem like the hardcore MoM guys ever really moved over to JEE. Maybe I‘m wrong about this, but I don‘t think so.
Back then, there was also a lot of talk about P2P. Sure you could do it with JMS, but it felt kind of like XML: so overprescribed by the time it got to the station, all logic for its being there had dropped to nil. There were a lot of people, including Sun, talking about lightweight P2P. Some cool project ideas. Went nowhere.
Enter Akka. Is this just another version of the same carnival? I don‘t think so. There is a bit of a gas cloud forming around Akka, but the team seems pretty blowhard free. They also don‘t seem like they are going to be the next cult, chanting their leaders initials like a bunch of brainwashed zombies. And frankly, let‘s keep something in mind here: this is a special kind of framework. It‘s basically just making the scheduling of your code its business, and not much else, which is pretty damned awesome. I am so tired of hearing a raft of crap around how you have to write in a new language to really get concurrency, and to understand what your code is doing. Utter nonsense. It is true that the Java code you will write in Akka (should you decide not to do Scala yet) is going to be a tad verbose, but Folks, keep in mind: it‘s no worse than you would have if you were using just the concurrency package. And from my short experience, if you are doing things that are computationally trivial, you are probably going to be composing Futures quite a bit. As you do more things with Agents, you will see that that‘s mostly going to consist of wiring components into them and then adding the message logic for receiving Work requests, and dispatching replies. In other words: the actual Akka fixtures should probably stay pretty Lean.
The documentation for Akka is ok, not great. My biggest suggestions would be:
- Much better working examples people can run and look at. For instance, what is the point in doing a Hello World that returns a string??? This is a concurrency/Agent Framework, guys. I suggest a Hello World where the two words are translated by calling a web service and then stuck together. [Yes, this is the bane of most software documentation and books about software.]
- Seriously, these guys should do some sequence diagrams. It‘s super easy for the whole thing to start looking like a rabbit hole. ‘Der, here, load up your futures in this sequence, chunk that into a flat map then do a couple onCompletes and you‘ll be all set.‘
- I think there‘s a good DSL in here for the Java side of this, but since these guys have already talked themselves into Scala, I doubt one is forthcoming. I might turn a few cycles on this. Especially the composable futures would lend themselves to more help (you could argue that what‘s there now is quasi-DSLish, since there are fluent builder style call chains).
- There are a million cool things you can do with agents. The book in the sidebar is literally one of my favorite tech books of all time [click on it to go to it on Amazon]. It‘s stupid expensive, but… It will really turn your head around about how to make code componentized, logical, and ruthlessly collaborative.
There are some unintended collateral damages that come with this thing:
- Support for 2 languages is kind of a drag because when you are searching, you are switching back and forth. That doesn‘t bother me that much, but I still hear people complain about the fact that the Design Patterns examples are in C++. Long term, this is going to make things harder. Hopefully it will spur the team to go the extra mile and redouble their efforts on their documentation. I would give it a B right now. Make it an A and do it soon, it will make a huge difference in your adoption curve.
- It‘s hard to search for a lot of stuff. I mentioned ask before. I am still not totally clear on whether the issues with Java 7 are resolved. Is the new Fork/Join stuff available?
- Don‘t treat Java as a second-class citizen.
- Make Logback work out of the box. It‘s pretty stupid that it doesn‘t now (it finds my logback.xml file and yet I still had to put some Joran code in to see my damned messages).
I haven‘t even mentioned Supervision, which is one of the most exciting parts of this framework. Will blog more on that when I get to using it. Suffice it to say I have big plans for it.
Akka and Play are the best bid for rolling up the fascinating component ideas that were dangled in our faces over the last decade and a half, during which time only pale shadows of their like were ever offered up. Supper‘s definitely ready….
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)