Hacker News new | comments | show | ask | jobs | submit login

I have coded one significantly large system using Akka. I think conceptually, actors are quite simple and powerful. But in practice with Akka, I hated the fact that I couldn't just set a breakpoint and just follow a message all the way through the system via multiple F7's. Every time I got to a "send" call, I would need to find out which of the other 200 actors in the code actually dealt with that message, set another breakpoint, and keep going. Because all you have at runtime is an ActorRef which could really be anything, and all the sends are asynchronous. This was perhaps in large part due to the fact that there was a lot of Akka 101 learning going on during early development so people went a bit crazy with actorifying everything. If in doubt, create a new actor. Because erlang, resilience, Telcos use it, supervisor hierarchies, self healing, and a blog I read last week. Questioning it was a case of the emperor's new clothes. Interestingly none of the big ticket things that Akka was sold to the dev team on ever eventuated.

A while into the project, my team and I were responsible for delivering a subcomponent within the system. We did so with extreme prejudice to only using actors at the very edges and entry points where a bit of asynchronicity was required. But everything within the service boundary was just plain old Java. This was the easiest to understand and maintain part of the system, as attested by another team who we handed over the entire codebase to. Guess which part had the least bugs? Most extensible?

I don't know if akka has improved since then, but the debug workflow was such a departure from the normal way of doing things on the JVM it was enough to put me off and then steer clear of it in general. There are definitely other patterns and libraries I would reach for first.




I have come to realize that breakpoint style debugging should be avoided. Atleast for people working on Services. Prefer logging, or other variants like Event History, State Change history, etc.


Why?


Makes it easier to jump to distributed systems that span multiple processes or machines, where you can’t just set a breakpoint. Also makes it easier to debug production systems, where you may have logs but can’t jump back in time to attach a debugger.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: