Finite state machines with Akka | Hacker News Reader

Finite state machines with Akka

codurance.com

90 pointspedromsantos8 comments

Worth noting that Erlang also has a new gen_statem in R19 coming in June. It looks like a big upgrade to gen_fsm!

Not only that but ssh protocol in R19 will be implemented as a gen_statem, providing a real life usage example for it.

I also liked that Ericsson engaged with the community and considered input and updated code accordingly as they worked on it.

You can see the whole process and discussion in:

https://github.com/erlang/otp/pull/960

Awesome, I'll definitely have a play with the :ssh module then, even if only from the Elixir side of the fence.

Just been to ElixirConf here in Europe and was super impressed with Erlang Solutions guys and the general quality of the Erlang and Elixir people. Lots of interesting chats!

:-)

What about Kafka's at-least-once semantics ? Is that being dealt with ?

Your question is hard to understand.

https://kafka.apache.org/08/design.html

"So effectively Kafka guarantees at-least-once delivery by default ...."

Edit: Downvote if you want. I was trying to help you.

GP asked how this system deals with Kafka's at least once semantics. Pointing out that Kafka has at least once semantics is redundant.

What GP was asking: what happens if Kafka delivers the "item added" event twice, but the "item deleted" event only once? Do you end up with an invalid/unrecoverable state?

Disclaimer: I'm the author of the post.

In this particular example, both events (item_reported and item_deleted) end up in destructive actions identified by unique id. That idempotency makes safe working with Kafka's at-least-once semantics. You can see that it's safe to execute several times this line of code:

  val newItemsToBeDeleted = items.filterNot(_ == item)

Akka is good, the only thing I don't like is that with actors sometimes type safety is lost, or at least takes some effort to enforce at compile time.

Reply on news.ycombinator.com