4 ms·

What would be the point of async/await when goroutines are already n:m green threads?

• hot_gril 2y ago
  More familiar and convenient syntax
  • eurleif 2y ago
    `await f()` is more convenient than simply `f()`? I don't get it.
    • hot_gril 2y ago
      I don't want to have to make a channel every time for something so simple. Also, was Googling how you execute two things at once then wait on both in Golang, and https://www.reddit.com/r/golang/comments/15xp94w/asyncawait_in_golang/ https://www.reddit.com/r/golang/comments/15xp94w/asyncawait_... came up. This is honestly how I judge ease of use, how simple are answers to simple questions. The agreed-upon response was to use a library.
      • eurleif 2y ago
        Channels and `async/await` are orthogonal. Channels are a way of communicating and coordinating between concurrent tasks; `async/await` are an alternative to blocking function calls (or an alternative form of blocking function calls, perhaps). There are implementations of channels for environments with `async/await`, where you would use syntax like `value = await channel.receive()`. What you may be getting at is that in an environment like Node.js, where everything runs in a single OS thread and there is no parallelism, there's a reduced need for coordination features like channels (or mutexes), because it's safe to mutate shared memory. But that too is orthogonal to `async/await`: the Python library gevent, for example, uses ordinary blocking function calls while running concurrent code in a single OS thread, making it safe to mutate shared memory; and conversely, C# allows `async/await` to be executed across multiple OS threads, making it unsafe to mutate shared memory.
        • hot_gril 2y ago
          What I mean is, to do the equivalent of async/await in Golang, you need to use channels. As I understand it, you can wait on a goroutine to finish by waiting on its channel to return something. Async/await would simply be syntactical sugar on top of that, it's already close. One implication of async/await is that you need some kind of greenthreading or thread pool because you really don't want to spawn OS threads for it. In JS it's an event loop, Python and (I think) Rust have that too now as a lib, and Golang already has its own greenthreads. And btw, the reason JS doesn't have threading is because for those applications, you don't need fast communication between parallel tasks like the things Golang is made for. NodeJS supports subprocessing, and the tasks will probably not talk to each other at all, though there's IPC if you really want it.
          • lenkite 2y ago
            You don't need to always use channels in Go. You can use the facilities of the sync package (https://pkg.go.dev/sync https://pkg.go.dev/sync) to communicate across go-routines.
  • hu3 2y ago
    I don't think introducing function coloring to a language that managed to avoid it, is a net gain. Go brilliantly borrowed ideas from Limbo, Oberon-2 and Newsqueak. Throwing that away by polluting with async/await would be reason for riot imo.
    • hot_gril 2y ago
      That's ok, I'll just use the other languages that have it
      • hu3 2y ago
        Fair enough. Just keep in mind that in the common runtimes of the most popular language, JavaScript, your async/await code is usually a single threaded event loop. Which is very different from Go's green-threads implementation.
        • hot_gril 2y ago
          Yes, but async/await doesn't mean you need an event loop.