> 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 l

> 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.