2

OK. We've got this tiny little pet project of mine (work related)…

I rescued it from the git archive, simply put: someone hot glued an elasticsearch scroll + document processor (processing) together.

After a lot of refactoring, I had an simple, much improved (non-parallel) Akka Worker System without an Akka topology / hierarchy.

I left out the hierarchy at first, because I didn't know Akka at all.

I've worked with a lot of process workflows, and some systems that come very close to IPC, so I wasn't completely in the dark.

Topology requires knowledge / creation of a state machine / process workflow. And at that point of time I just had... Garbage. Partially working garbage.

I finished yesterday the rewrite into several actors... Compared to before, there are 8 actors vs 2... And round about 20 classes more. Mostly since I rewrote the Receive Methods of Akka as Command DTOs... And a lot of functions needed to be seperated into layers (which where non existent before)

Since that felt more natural than the previous chaos of passing strings or other primitive types around, or in the worst case just object....

(Yes: Previously an Actor was essentially a class with one or more functions "doEverything" and maybe a few additional functions which did everything - from Rest Client to Processing)).

Then I draw the actual state machine based on everything I've written in the last weeks and thought about how to create the actual topology and where / how parallelizing might make sense.

Innocent me stumbled in the Akka Docs on Akka Typed... (Didn't know it existed, since I'm very new to Java and Akka).

Hm, that sounds an a lot like what I did. In an different way, yes. But not so different that it might be VERY hard to port to.... And I need to change (for implementation of hierarchy) a few classes....

[I should have known at this stage that my curiosity would get the best of me, but yeah. Curiosity killed the cat.]

Actually the documentation is not bad. It's just that upon reading the first more complex examples, my brain decided to go into panic state.

The've essentially combined all classes in one class in all source code examples [which makes sense more sense later], where it is fscking hard for an chaotic brain like mine to extract information....

https://doc.akka.io/docs/akka/...

The thing is: It's not hard to understand… actually very simple.
It was just my brain throwing an fuck you tantrum.

So I've opened more examples in other tabs and cross referenced what happened there and why...

Few frustrated hours later I got that part.... And the part why it's called Akka Typed. It was pretty simple....

Open the gates of hell, bloody satan that was too easy for fucks sake.

Nooooow.... I just need to port my stuff to Akka Typed.

Cause. Challenge accepted, bitch - eh brain. You throw tantrum, you work overtime. -.-

I just cannot decide wether to go FP or OOP.

Now... I'm curious wether FP is that hard... Hadn't dealt with it at large before.

Can someone please stop me... I'm far too curious again. -.- *cries*

Comments
  • 0
    I mean, I love akka, and I love FP. I'd encourage the FP route for actor model in most cases, but typed/class-oriented can be easier if you are used to OOP.

    FP isn't really hard, it's just rigorous. You're defining types and states they go through in your application rather than data with operations. The end going being to make your software "provable."
  • 0
    @SortOfTested Yes. Actually I was amazed how natural Akka felt (except for some Java*isms).

    My pain point with the Akka examples was the Java concept of nested classes (totally forgot to mention, oopsie).

    It's... for me a broken concept.

    My brain went into panic state because I read Command multiple times without realizing that the nested class (eg DeviceGroup.Command) was meant...

    I must read about that part at the weekend, because I actually don't want to go that way... It reminds me too much of PHP class goo (one file... Oh so many classes).

    Otherwise, I think FP and I are somehow already friends.

    I always liked OOP design mixed with elements of FP. My DTOs are value objects, hence not mutable. My actors never mutate inner variables, only initialize them. Everything "in" and "out" are DTOs / value objects...

    (one very painful lesson from PHP - as in a loosely typed language mutating stuff can lead to a hell of lobotomy, since even changing the type is possible, which leads to a nightmare of debugging)
Add Comment