3 ms·
The point is that having to think about color of the function is disadvantage and needless complexity > If I write a block of JS in an async context, I can be
by adql 4y ago
The point is that having to think about color of the function is disadvantage and needless complexity
> If I write a block of JS in an async context, I can be 100% guaranteed that the only times when any other task may interfere with my functions execution are explicitly marked with `await`. I love this!
You only need to think about it because runtime isn't parallel. If you want ordering in execution you should be using synchronization primitives anyway.
In Go doing "async" via channels could possibly start running the code the instant you instantiate it, on however cores there are available. Go have problem of that requiring a bunch of boilerplate (as there is no macros), but with generics now it is manageable and I can just say "here is function, run it on all elements of the slice in parallel" very easily and it all be pretty reasonabe, like
out = ParallelMapSlice(mapFunc,8,in)
All done async without thinking about async.
- jakear 4y agoIf mapFunc reads state it also writes, you should be thinking about async. If it doesn't, the problem isn't all that interesting. Though I did admit in the parent comment that Go's approach is reasonable. It should be noted that similar code is possible in JS with WebWorkers. Async/Await is more for same-thread concurrency.