3 ms·
Golang recently folded on the whole "no generics" decision, which throws a lot of dust into the air. Personally I'm waiting for them to add exceptions and async
by hot_gril 3y ago
Golang recently folded on the whole "no generics" decision, which throws a lot of dust into the air. Personally I'm waiting for them to add exceptions and async/await.
- eurleif 3y agoWhat would be the point of async/await when goroutines are already n:m green threads?
- hot_gril 3y agoMore familiar and convenient syntax
- eurleif 3y ago`await f()` is more convenient than simply `f()`? I don't get it.
- hot_gril 3y agoI 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 3y agoChannels 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 3y agoWhat 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 agoYou 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 3y agoI 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 3y agoThat's ok, I'll just use the other languages that have it
- hu3 3y agoFair 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 3y agoYes, but async/await doesn't mean you need an event loop.
- theshrike79 3y agoThey didn't "fold". The plan was to add generics for many years, they just didn't want to "add generics" to have a checkbox done. They wanted to do it in a way that's useful and practical for the use-cases Go is best suited for. (Still haven't needed generics in any of my Go projects)