Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I strongly agree with the premise that an orchestrator-centric approach is preferable to event spaghetti for a lot of business process use cases.

Another (maybe more mature) alternative to Infinitic is Camunda, who have been pushing this rhetoric for over a decade.

My problem with both is that neither feel very modern, in the sense that they are tied to (in Infinitic's case) or strongly favor (in Camunda's case) Java-centric development, don't have a great developer experience story, and don't feel very cohesive with the language.

What I'd love to see is someone tackling this for smaller orgs where the above tradeoff in developer experience isn't worth the gains, i.e. orgs with <100 engineers. Something where you have a single source of truth for your processes and schemas, with version control, that directly yields strongly typed integrations & hooks into any language, with a great local developer experience and deployment story.

Camunda requires too many magic strings and schemas to be kept consistent across services for that, and Infinitic forces me to use Java or Kotlin which I don't want.

A "simple" solution might be to have declarative process and schema definitions in some DSL for version control, which auto-generates schemas, types etc in whatever language, giving me both strong types, intuitive local development, and clear deployment story through my existing CI/CD.



Thank you for your comment. Highlighting the need for a descriptive format to orchestrate services implemented in multiple languages is a valid point. While Infinitic currently uses Java's interfaces, adopting a more generic and language-agnostic solution like Protobuf is a sensible approach that could promote better interoperability across different tech stacks. Then we need a DSL. Again, Infintic is using Java/Kotlin, but I'm thinking to the ideal solution as a new simple language in which Protobuf object are first-class citizen and that can be resumable (i.e whose internal state can be safely stored to be resume later). It's not as easy as it sounds as a lot of legit issues arise regarding versioning.


> Then we need a DSL.

Or perhaps just the data structs already expressible in Protobuf, come to think of it. Versionable and textual thus git/etc-able.


Some things never change. Devs calling "any pattern or code they dislike" spaguetti is one of them. Just like "clean".


Any code you didn't write today is legacy code!


> Any code you didn't write today is legacy code!

Any code you didn't write is legacy code!


I worked with somebody whose brain just didn't brain with mine. anything she wrote was unreadable to me, and anything I wrote was not "simple" or "understandable" enough.


Look at the biased way you write about the situation. This is the fundamental attribution error. If you can't read her code, it's her fault (you implied that). And if she can't read your code, it's also her fault (you implied that).


I said it was unreadable to me. I meant what I wrote. I did not imply it was her fault. it was presumably readable to others in the team, just not to me. the only way I could figure out what was going on was by adding a lot of printf and running small parts of the code to work it out. the documentation really didn't tell me anything that I needed to know for that purpose.

the quotes represent words that she actually said. in the end I did re-write my code in a way that she would finally approve the review and now I can't read the code either.

she's diagnosed with autism. I'm diagnosed with autism. not only are we not neurotypical, but we're also so different that our code was mutually unintelligible.




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

Search: