3 ms·
Interesting! I'm not very knowledgeable about this topic so I'm wondering why workflows would rely on code that doesn't remove the sources of non-determinism? (
by aatd86 3y ago
Interesting! I'm not very knowledgeable about this topic so I'm wondering why workflows would rely on code that doesn't remove the sources of non-determinism? (runtime errors, lack of proper serialized synchronization logic etc...)?
Or is the issue that the evolution of a language might introduce additional sources of non-determinism?
So merely upgrading without checking for these wouldn't be safe if code execution depends on the behavior of a specific runtime?
(that would probably for code that never fails at runtime I assume which also seem to be a pretty stringent requirement?)
The advantage of a virtual machine would then be that the full execution trace of the instructions can be recorded and then replayed, regardless of the higher level changing semantics?)
- kodablah 3y ago> why workflows would rely on code that doesn't remove the sources of non-determinism? We can't always sandbox every environment to remove these sources at a language level. Sure in JS/TypeScript we can use V8, but in Go there aren't many good ways to do this (all options, e.g. interpreters, have tradeoffs). So we offer deterministic alternatives for non-deterministic language features/stdlib and rely on authors and static analysis for catching misuse. > Or is the issue that the evolution of a language might introduce additional sources of non-determinism? This is less concerning, but still can be a concern. > So merely upgrading without checking for these wouldn't be safe if code execution depends on the behavior of a specific runtime? Technically true, though the bigger concern is updating code you think wouldn't cause a change in the order of upstream operations (what we call "commands") but does.