3 ms·
> Even Go, that prides itself on the good support for parallelism, fails once you actually want go get results back. It's doable if you're willing to build a v
by q3k 5y ago
> Even Go, that prides itself on the good support for parallelism, fails once you actually want go get results back.
It's doable if you're willing to build a very thin abstraction over whatever you're trying to parallelize keeping in mind all possible edgecases [1] and how you'd like to handle them.
A generic `run N things in parallel and collect their results` function would be nice, but would probably end up being quite unwieldy in comparison to just writing out a purpose-specific function for what you exactly need.
[1] - Error handling, timeouts/cancellation, maximum amount of processes running in parallel, wait-for-full-join vs. returning results as they appear, introspection of currently running subordinates, subordinate output streaming/buffering/logging, ... A lot of things to consider when you're trying to build something universal, but that are easy to solve/ignore when you're building something purpose-specific with known constraints.
- tgsovlerkhgsel 5y agoThat's the thing though... if the options are "write and test 30 lines of custom parallelism code to handle this stuff" or "everyone waits twice as long for their results", in practice most developers choose the latter. Imagine if instead of that, you could do: foo, bar, []err := await getFoo(), getBar() if len(err) > 0 { return nil, nil, fmt.Errorf("Frobnication failed: %s", err) } return foo, bar, nil Of course, JavaScript having exceptions as the main error-raising approach and `await` supporting them makes that a lot easier.