ExecutorService - goto in disguise?

[Arkadiusz Gasiński]

I gotta admit I was mostly focused on the control flow aspect. I guess the
structuring of the code part may not be so obvious for me to spot as I'm
too used to the structure that using Future brings and it feels so familiar
by now that thinking of something else requires substantial mental effort
;)

But if you could share an exaggerated example of how Future breaks the
structuring of the code, then I'd be really thankful.

Arek

On Sat, May 21, 2022 at 8:54 AM Alex Otenko <oleksandr.otenko at gmail.com>
wrote:

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