3 ms·
This answer sums up my feelings best: http://stackoverflow.com/questions/7479276/what-is-the-main-difference-between-net-async-and-google-go-light-weight-threa
by bradfitz 13y ago
This answer sums up my feelings best:
http://stackoverflow.com/questions/7479276/what-is-the-main-difference-between-net-async-and-google-go-light-weight-thread http://stackoverflow.com/questions/7479276/what-is-the-main-...
It's good for C#, but still a language wart that could be built-in. I like that Go only has one set of APIs for everything, not the sync way and the async way.
It's sad that C#, which started out as a fixed-up Java, is now growing its own warts.
Of course, Go's not perfect either.
- test-it 13y agoVery interesting. I haven't yet tried Go, but I don't see how it could match the performance of C# API with a single function. C#'s async methods offload any IO to the process IO completion port threads, thus freeing the current thread to do more work.
- dragonwriter 13y ago> I haven't yet tried Go, but I don't see how it could match the performance of C# API with a single function. C#'s async methods offload any IO to the process IO completion port threads, thus freeing the current thread to do more work. Go generally uses synchronous functions, but a function in Go can be the subject of a "go" statement (sharing the name of the language should give an importance of how central this feature is), which causes the function to be executed as a goroutine (that is, asynchronously using an M:N threading model.)
- deleted 13y ago[deleted]
- wolf550e 13y agoYou meant to reply to test-it, but instead it looks like you're teaching a member of the Go team how Go works.