Hacker News new | past | comments | ask | show | jobs | submit login

I see your point. But so far we didn't hear many complaints about this feature from the users. The main problem is in forgetting to version code that changed. But the system has protections against such cases.

It doesn't end up in spaghetti code as old branches are proactively removed after they are not needed anymore. Temporal provides APIs that allow to count number of workflows using each version.

I don't think it is a leaky abstraction as it is indeed a part of the business logic of deciding how old version of the state should become a new one. I don't think there is a generic solution that allows implicitly migrate old state to a new state on any long running computation.




You might find the concept of Edit Lenses to be useful. A good writeup is: https://www.inkandswitch.com/cambria.html


I wish it were that simple :).

A workflow is not just externally stored data with a well-defined schema. It is the computation's whole state, including threads blocked on API calls and local variables on the stack. So it is not possible to define translations between different versions the way Edit Lenses do.


So a process checkpoint? They make me anxious.


Why not assuming that you can roll it back to any previous state any time later? Temporal supports such rollbacks.




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

Search: