ExecutorService - goto in disguise?

[Arkadiusz Gasiński]

Hi,

I'd like to know your opinion on the question from the subject - do you
think it's justified even to make the comparison between the
ExecutorService and goto?

Nataniel Smith, frequently referred to in Loom talks, argued that any form
of thread spawning, futures, callbacks, and promises are all variants of
goto.

I've been trying to connect these dots in my head for a while now, and it
somewhat struck me when I read the following paragraph of the SC JEP
<https://openjdk.java.net/jeps/428>:

Any code with a reference to a Future can join it (i.e., await its result
> by calling get()), even code in a thread other than the one which
> obtained the Future. In effect, *a subtask started by one task does not
> have to "return" to the task that submitted it*; it could "return" to any
> number of tasks, or even none.


 Especially the bolded part, which, to some extent, sounds like "the called
method does not have to return to the callee" (when you have a construct
like goto in your language).

Agree, disagree?

If agree, would that mean that eventually, ExecutorService becomes the
low-level building block for other high-level constructs, and the majority
of developers won't even have to bother with it?

Thanks,
Arek