On the future of Akka and Lightbend
discuss.lightbend.com
On the future of Akka and Lightbend
1–10 of 50 posts
Re: On the future of Akka and Lightbend
#2Re: On the future of Akka and Lightbend
#3Re: On the future of Akka and Lightbend
#4Biggest problem I had with Akka was that it was that it worked better with Scala than Java. As Java recently has re-taken most of Scala's momentum its a bit awkward fit.
Re: On the future of Akka and Lightbend
#5If you’re looking for a straightforward Java framework similar to Play v1 check out Ninja:
https://www.ninjaframework.org/
For me at least, it hits a sweet spot of enabling fast productive development and maintainable code.
Re: On the future of Akka and Lightbend
#6It’s a shame that the Play framework is being abandoned. v1 had a lot of great ideas, but v2 kind of jumped off the cliff into Scala lala-land, where it got lost in the weeds. It never really recovered. If you’re looking for a straightforward Java framework similar to Play v1 check out Ninja: https://www.ninjaframework.org/ For me at least, it hits a sweet spot of enabling fast productive development and maintainable…
Ninja is pretty cool. It works well with Kotlin, which is what I reach for today with the JVM, but tbh the easy path today is pretty much Spring Boot so I have some trouble rationalizing using anything else.
Re: On the future of Akka and Lightbend
#7Has anyone had great success with akka? It seems like it could definitely solve some problems elegantly. My team has had trouble with maintainability due to complexity (not clear if that's inherent in akka or just with how we implemented it). It can be somewhat managed by senior engineers but has seemed to be difficult for junior engineers to effectively maintain akka code.
The Akka actor model requires a different mode of thinking which can cause problems for experienced engineers. Ideas such as 'let it crash' and at-most-once-delivery are not trivial. Basically systems design based on resilience instead of robustness.
When Actor based systems are well designed, they can be extremely powerful, scalable, resilient and adaptable.
Small nitpick. I found that akka-streams missed many useful primitives. For our toolkit, I designed flows with retry-logic, flows with cache lines and flows with metric measurements (sending data to Datadog).
Re: On the future of Akka and Lightbend
#8Has anyone had great success with akka? It seems like it could definitely solve some problems elegantly. My team has had trouble with maintainability due to complexity (not clear if that's inherent in akka or just with how we implemented it). It can be somewhat managed by senior engineers but has seemed to be difficult for junior engineers to effectively maintain akka code.
At glngn we didn't use akka streams (outside of akka http) but did use event sourced, persistent entities powered by akka typed in clustered mode. Deployed to k8s. Which definitely took effort to set up nicely and enable smooth deployments. Our clusters were not huge so many problems did not show up (split brain).
I haven't used other systems that provided an equivalent to akka typed persistent entities. I can't compare akka in that sense. However the event sourced persistent entities model is really, really effective. Definitely a different paradigm: some stuff is trivial that would otherwise be a trial.
I suspect many of the benefits could be achieved by using something like Kafka feeding non clustered nodes. But never tried.
Re: On the future of Akka and Lightbend
#9Biggest problem I had with Akka was that it was that it worked better with Scala than Java. As Java recently has re-taken most of Scala's momentum its a bit awkward fit.
Same story with Lightbends Play Framework. Using it from Java is abysmal.
Re: On the future of Akka and Lightbend
#10Has anyone had great success with akka? It seems like it could definitely solve some problems elegantly. My team has had trouble with maintainability due to complexity (not clear if that's inherent in akka or just with how we implemented it). It can be somewhat managed by senior engineers but has seemed to be difficult for junior engineers to effectively maintain akka code.
This being said, I've been burned already several times by the complexity and its raw power. The codebase tends to become verbose and difficult to navigate (everything being an ActorRef). Debugging is difficult and coding is challenging for junior engineers, as you said. I found it very unforgiving to mistakes, and it's easy to shoot yourself in the foot if you use the abstractions without knowing very well what's going on under the hood. Edge cases can be very tricky to manage.
I'm still very conflicted about it. One one side the services powered by Akka are quite stable and performant, but I'm not sure the complexity justifies the means.