[explaininjs]

Coming from a heavy TS background into a go-forward company, I’d say the main thing you get with async is it makes it incredibly obvious when computation can be performed non-sequentially (async…). For example, It’s very common to see the below in go code:

   a := &blah{}
   rA, err := engine.doSomethingWithA()
   b := &bloop{}
   rB, err := engine.doSomethingWithB()

This might have started out with both the doSomethings being very quick painless procedures. But over time they’ve grown into behemoth network requests and very thing is slow and crappy. No, it’s not exactly hard to spin up a go routine to handle the work concurrently, but it’s not trivial either - and importantly, it’s not immediately obvious that this would be a good idea.

Contrast to TS:

   let a = {blah}
   let [rA, err] = engine.doSomethingWithA()
   let b = {bloop}
   let [rB, err] engine.doSomethingWithB()

Now, time passes, you perform that behemoth slowing down of the doSomethings. You are forced by the type system to change this:

   let a = {blah}
   let [rA, err] = await engine.doSomethingWithA()
   let b = {bloop}
   let [rB, err] await engine.doSomethingWithB()

It’s now immediately obvious that you might want to run these two procedures concurrently. Obviously you will need to check the engine code, but any programmer worth their salt should at least seek to investigate concurrency when making that change.

I wouldn’t be bringing this up if I hadn’t made 10x+ performance improvements to critical services within a month of starting at a new company in a new language on a service where the handful of experienced go programmers on the team had no idea why their code was taking so long.

[hombre_fatal]

Of course, the other nice thing about the JS example compared to Go is that it's trivial at the callsite to do this:

    const [[rA, errA], [rB, errB]] = await Promise.all([
      engine.doSomethingWithA(),
      engine.doSomethingWithB()
    ])

At least these days you can ask an LLM to write the WaitGroup boilerplate for you in Go.

[masklinn]

Which has to do with the incredible lack of expressivity of Go, not with the concurrency model. Nothing precludes doing exactly the same thing with thread-like constructs in an expressive language.

Not to mention waitgroups are way overkill for this. You’d just use a channel or two. Or an errgroup if you want to be fancy.

[explaininjs]

Indeed. And breakpoints and stepping across concurrent context actually works in JS, which is nice.

[sapiogram]

WaitGroup/ErrGroup doesn't even work here, because the functions return data. I mean, you can use ErrGroup, but it requires additional error-prone concurrency orchestration to work.

[Kamq]

Yeah, go's a little boilerplatey, but you have to option to run two sync things concurrently as well with something like:

    type result[T any] struct {
        el T
        err error
    }
    chanA := make(chan result[aResultType])
    chanB := make(chan result[bResultType])
    go func() {
        defer close(chanA)
        a := &blah{}
        rA, err := engine.doSomethingWithA()
        chanA <- result[aResultType]{
            el: rA,
            err: err,
        }
    }()
    go func() {
        defer close(chanB)
        b := &bloop{}
        rB, err := engine.doSomethingWithB()
        chanB <- result[bResultType]{
            el: rB,
            err: err,
        }
    }

    resultA := <- chanA
    resultB := <- chanB

[dumbo-octopus]

One could theoretically pull out the shared boilerplate to a utility function like:

    func runTask[T any](task func() (T, error)) chan result[T] {
        ch := make(chan result[T])
        go func() {
            defer close(ch)
            res, err := task()
            ch <- result[T]{ el:res, err:err } }()
        return ch }

Does that sort of thing happen much in practice?

[jerf]

Yes, it does, and Go is perfectly capable of it, and many libraries exist for you to choose which exact method suits your problem and temperment.

One of the common pasttimes in the threaded versus async debate is to present code in which one side uses all sorts of helpers and patterns and libraries and the other side is presented through writing it "raw". The great-grandparent of my post here is guilty of this. While there are interesting reasons to debate threaded versus async code, this is not one of them. Both of them are absolutely capable of writing the moral equivalent of "output = parallel_map(myMapFunc, input)" and all similar operations to within practical epsilon of each other, and anyone citing this sort of thing as an argument on either side should probably be ignored. And both languages will feature code written by people who don't know that, and it shouldn't count against either.

[explaininjs]

No… I fear you’ve missed the entire point of the matter, which is that async/await requires that you must go all the way up the call stack explicitly “await”ing things when you have introduced an “async” call (or similar wide spread changes to that effect). There’s no special magic utility function you can call you hide it away. That’s the whole point – and a very good thing, this thread argues.

[jerf]

No, it is perfectly feasible to abstract around it. It's just that the abstractions are also colored. But there is no more a rule that you can only "await" a promise right in the exact code where you created the promise than there is that the only way to use threads is to spawn them right on the spot and then wait for the result right on the spot. Critics of both async and threads are just dead wrong on this, and observably, objectively so, since libraries in both cases not only exist, but are readily available and abundant.

And I'm admitting this "against interest", as the lawyers say. I'm not striking a disinterested "middle of the road" pose here. I'm hugely on the side of threads. But it is still not a relevant criticism of async. You can easily "parallel map" with either abstraction and you are not stuck unable to abstract the control flow in either case.

[Kamq]

You can, but I didn't want to introduce any extra constructs from the original example.

And this is a bit of a weird case, at least where I am. I tend to have a bunch of things to process and have one goroutine sending keys/indices/etc to a channel that multiple workers are processing off of.

We did have an abstraction for that at one point, but there were enough edge cases in our domain that we either had to develop a config system or rip it out and go back to writing each one (we went with the latter after an attempt at the former went really bad).

[ackfoobar]

Now handle the following that is painlessly solved by runtimes with structured concurrency:

If A failed, the whole function is failed, and we don't need B any more. To save resources we should cancel B. And vice versa, cancel A if B failed.

[jerf]

    import github.com/carlmjohnson/flowmatic

    func whatever(ctx context.Context) {
        err := flowmatic.Race(ctx, taskA, taskB)
    }

Provide your definition of taskA and taskB, of course.

As I said in another message, this is not a particularly fruitful line of attack in either direction. All the languages in question are perfectly capable of abstractions.

[ackfoobar]

I don't like that the return values of the tasks has to be communicated with side effects, but I'll concede that it's quite painless.

I guess I'm just still salty when someone commented (in another post a long time ago) that golang only has `go` (compared to `launch`, `async`, and `coroutineScope` in Kotlin) and is simpler.

> All the languages in question are perfectly capable of abstractions.

I don't think async functions in JS can be cancelled though.

[jerf]

"I don't like that the return values of the tasks has to be communicated with side effects, but I'll concede that it's quite painless."

Me neither, however, it is generally the most flexible approach and I can see why a library takes it. If you want to communicate it via the return, you also have to impose a restriction that the tasks all return the same type. I think it makes sense for a library to work this way because you can easily add this around the library call yourself, but it's more difficult to go the other way. (Not impossible, just more difficult.)

"I don't think async functions in JS can be cancelled though."

Poking around, it looks pretty hard.

That said, cancelling in generally is very difficult in imperative languages, so even as someone who finds async in JS quite distasteful I can't dock too many points. Go basically just reifies the JS solution into a standard community practice, which is definitely an improvement since you can largely rely on it being supported everywhere, but one could reasonably debate how good it is. It is occasionally a problem that if you want to cancel an ongoing computation you may have to have your code manually check a context every so often, because there's no "real" connection between a context and a goroutine.

[Kamq]

So, context.Cancel?

[asp_hornet]

Only if those doSomething methods were written as asynchronous to begin with.in your original example, doSomethingA was simple, why would it be an async method. If your answer is write every method async for a rainy day, then whats the point.

[explaininjs]

No… that’s the whole point. If you change them to be async, the language forces you to go and rethink what implications that has for the callers. This is a good thing, dumbly sequenced operations are terrible UX. And UX is far more important than whatever it is they call “DX”.

[asp_hornet]

I’d rather just stick to languages that don’t have colored functions. You don’t need to be forced to think about this. Your tools manufactured this issue.

[jayd16]

Honestly, despite that blog, async coloring is a feature. The pattern enforces implicit critical sections between yields and the coloring is how the dev can know what will yield.

[throwitaway1123]

This is a really interesting point. You almost never hear async function coloring being conceptualized as a feature rather than a hindrance. Async function coloring is kind of analogous to the borrow checker in Rust. It makes you think about concurrency the same way that the borrow checker makes you think about memory ownership and lifetimes.

[bloppe]

async is a great feature if you use it from square 1. If you start with a legacy codebase using callbacks and try to port it incrementally to async, you're gonna have a bad time. Otherwise, it's definitely a feature

[throwitaway1123]

Yeah upgrading a legacy codebase that uses callbacks is not fun, but if the callback functions follow the Node error first value second convention, then it's a little bit easier because you can just use `util.promisify` to convert them to promises in Node. There's also the new Promise.withResolvers method which helps a bit too [1].

[1] https://github.com/tc39/proposal-promise-with-resolvers

[explaininjs]

Yes. That blog has probably done more to negatively impact the industry than any other written work I know.

[fulafel]

For some reason requiring the programmer to use additional syntax at the call site to mark behavioural properties of called functions is not a popular language feature generally. I guess eg TypeScript could add it as a user extensible feature. Would it be useful to be able to require things like this in your internal API?

  let gizmos = nocheckperms lookupRequestedGizmos(request);

[jayd16]

You're trading complexity for expressiveness but the await keyword syntax is essentially unwrap sugar. Dereferencing a pointer is similar syntax.

It's possible to write a language where awaiting a task is done through a method on the task type. I don't think this is ideal because the whole reason you're using explicit yield points is so you can tell when something yields. Using method syntax makes that harder to see at a glance.