What Color Is Your Function? (2015)

Re:What Color Is Your Function? (2015) by ceronman on Tuesday May 19, 2020 @03:30AM (#23232226)

I'm not that experienced with Go, but it seems to me that the equivalent Go code to

    var foo = await bar();

    foo := bar()

Go concurrency is much nicer because it doesn't have colored functions. You can use the same functions and library both synchronously and concurrently in millions of goroutines.

[ Parent | on HN ]

Re:What Color Is Your Function? (2015) by tsimionescu on Tuesday May 19, 2020 @09:54AM (#23234880)

I don't think that's true.

    foo := bar()

In Go is equivalent to

    auto foo = bar();

In C#, in terms of semantics.

It is true that, due to the runtime implementation,

    go foo()

Is significantly less wasteful than

    new Thread(() => foo());

So there is less of a need for async code in Go.

But if you want to start multie things in parallel and await all of them, or if you want to create asynchronous workflows that modify shared resources without locking, you don't have any Go library or construct to help, which was precisely what async/await gives you.

[ Parent | on HN ]

Re:What Color Is Your Function? (2015) by speedgoose on Tuesday May 19, 2020 @04:03AM (#23232452)

Golang's concurrency can be much more cumbersome in some cases.

    const foo = await Promise.all(randomArray.map(bar));

I would have to google stuff to know where to start for the golang version.

[ Parent | on HN ]

Re:What Color Is Your Function? (2015) by hombre_fatal on Tuesday May 19, 2020 @04:17AM (#23232553)

Spoiler: 40 lines of wait group code in Go to implement that.

[ Parent | on HN ]