4 ms·
It's funny to hear someone say so many nice things about Akka. I work with Akka streams, actors and http every day and and while I agree that Akka is really we
by binwiederhier 5y ago
It's funny to hear someone say so many nice things about Akka.
I work with Akka streams, actors and http every day and and while I agree that Akka is really well documented, incredibly powerful and as you say polished, it is also the bane of my existence. It has made what could have been a simple application a rather painful experience for newcomers and even very senior engineers. The complexity of a framework like Akka is a huge barrier of entry for engineers and hinders development more often than it helps.
This is all obviously very subjective.
- waynesonfire 5y agoAnd, well, you're also most likely dealing with scala which isn't helping.
- tunesmith 5y agoI wonder if this is the type of complexity that comes by default with state machines? I have the same feelings with complex react component structures, as well. There is something about state machines where the command flow (that updates the states) feels "hidden", and I thus far haven't found a way to design or document this kind of programming cleanly. Instead I have copious documentation explaining what each combination of states means and how it can be triggered.
- worik 5y agoGetting OT, but I am a fan of state machines. They get big, but it is not right to confuse size with complexity. A huge state machine (size measured by the number of states) can be quite simple. Both in the whole, and each state transition can be isolated and considered independently
- FridgeSeal 5y agoAnd at least a large state machine has the dignity to make the state + transitions explicit. I’d much rather deal with a large state machine than something that does the same thing, but implicitly or inconsistently.
- Tanjreeve 5y agoI'm also very positive on Akka having been deep into Cluster and Streams and Actors over the last few months. The barrier to entry is high because the problems Akka is appropriate for are complicated. Every time I want to complain I imagine managing state in a performant way using "simple" threadlocks or Futures and then magnify that over a distributed application.
- sorokod 5y agoCan you share a use cases where Akka provides a more performant solution over ""simple" threadlocks or Futures" ?
- tunesmith 5y agoIf you're talking about Akka Cluster sharding, basically any situation where you have distributed objects that have their own state and behavior. I've had two projects where objects needed to stay in memory so they could receive messages, update their state, and then behave by sending messages to other objects. And it was too many objects to live in one server. The naive solution of data repositories and caching isn't really sufficient for this, and a horizontally scaled Akka Cluster Sharding setup with Persistence was the right solution given the requirements.
- Tanjreeve 5y agoIt's not going to be more performant than the constructs it's built off for a Hello World application. But unless you are a deep expert in concurrency and memory management (and have a team who can keep up) if you have a complex problem of concurrency and scale then the Application built in Akka will have high odds of getting to production readiness and stay maintainable while being performant and not getting bogged down in memory issues and shared state performance issues. That difference in the odds of success increases by an order of magnitude again once you start talking about distributed data.
- sorokod 5y agoI'd like to form my own opinion on the trade-offs. Can you share a use case please?
- dkarl 5y agoI guess when I've encountered complexity in Akka, I've felt that it was in proportion to the difficulty of the problem I'm solving. In the future, if/when I get to work with frameworks that solve the same problems while exposing me to less complexity, then Akka will be obsolete in my mind.