3 ms·
It IS different. In async code every single line of code must be async (or be very fast and i/o free), else you block everything. In Go, you can decide that a
by fooyc 10y ago
It IS different. In async code every single line of code must be async (or be very fast and i/o free), else you block everything.
In Go, you can decide that a call frame and all its descendants will live their own life in a separate thread of execution. But inside of that call frame, the code is just usual, synchronous code. It doesn't event need to know that it's a goroutine. It is just executing concurrently to other code, at a very low cost to the computer and to the programmer.
Go doesn't have async i/o by choice, it just doesn't need to. Though I'm pretty just there must be a libevent or libuv binding somewhere.
- tomjakubowski 10y agopcwalton said Golang's userspace threading model with Golang's I/O is equivalent to using "normal" threads with synchronous I/O, not that it's different from using threads and "async" I/O.
- stymaar 10y ago>> somehow different from everything just being synchronous and using threads > It IS different. In async code every single line of code must be async I think you misread the gp. He was not saying that Go code is not different from async code (what you understood), he said it's not different from synchronous code using threads.
- fooyc 10y agoYou are right, I misread it. I agree that there is no visible difference in the code, and that's exactly what I like. What's different, however, is how Go routines have much less overhead than OS threads.
- pcwalton 10y agoIt's not as much as you think, and goroutines also have significant overheads that OS threads don't. Most of the time, when people talk about goroutine overhead, they're referring to the small stacks, which are actually a property of GC--there are language implementations that are 1:1 that also have small stacks, such as SML/NJ.