I didn’t take that at all from the paper. I think they’ve provided valid reasons for fork bring harmful, which is that the original spec required that the chil

I didn’t take that at all from the paper. I think they’ve provided valid reasons for fork bring harmful, which is that the original spec required that the child process is exactly the same as the parent in all ways modulo its pid, and that this became bad due to the “all ways” qualifier. However, I think the difficulty in having better alternative is addressed in the paper. They suggest relaxing the “in all ways” requirement as a key to a replacement. In that context, the caller would have to understand what exactly they need behind the spawning, which makes sense. So I think they’re encouraging systems developers to a.) use these existing alternatives so that b.) we can deprecate the too coursely grained fork() and eventually c.) remove it usage entirely with some future breaking change. C seems like a pipe dream, but i think they argue quite clearly that A is actually already happening. Maybe B will come up not too long in the distant future.