Yes, killing the process is how cancellation of a batch job is normally done, for example in shell scripts. But it’s a heavyweight approach. Backend servers don

Yes, killing the process is how cancellation of a batch job is normally done, for example in shell scripts. But it’s a heavyweight approach. Backend servers don’t use a process per request anymore and they do need ways to cancel a request. Go’s Context API handles cancellation and timeouts at the request level, but it has to be coded manually; a badly-behaved goroutine could still leak and consume resources long after it’s cancelled. So it might be nice to have automatic support at the language level, to make guaranteed cancellation happen by default. This is the approach taken with structured concurrency. To preserve the invariant that a child task doesn’t outlive the parent, there needs to be a way to kill any unneeded child tasks when a function returns early. Totality checks seem like a poor substitute when what you actually want is to prevent resource leaks. I haven’t used Dhall, but it seems like a config language has different concerns?