ExecutorService - goto in disguise?

[Alex Otenko]

It's worse than goto, because more than one thing can join on Future.

I hope it is clear that the comparison with goto is not only in terms of
similarities of control flow, but also the bad part of structuring the
code. (Recall the "thou shalt not goto" commandment handed down to us by
our forefathers, and they received it from programming gods directly)


Alex

On Fri, 20 May 2022, 21:59 Arkadiusz Gasiński, <jigga at jigga.pl> wrote:

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