But, why? There’s already a kqueue/epoll-based async networking package for Go. It’s called “net” and it’s in the standard library. Even better, it uses Go to make it appear as if everything is synchronous.
A bit tongue-in-cheek, but is the runtime so bad at scheduling that this is necessary?
The Go runtime performance will be fine for most applications.
The README says a bit more about who the target audience is.
The goal of this project is to create a server framework for Go that performs on par with Redis and Haproxy for packet handling. It was built to be the foundation for Tile38 and a future L7 proxy for Go.
Hm. So, from the benchmarks, it looks like they’re comparing to a goroutine spawn per IO operation. I should play around a bit to see how it compares if goroutines do more IO before exiting, or get reused.
But, why? There’s already a kqueue/epoll-based async networking package for Go. It’s called “net” and it’s in the standard library. Even better, it uses Go to make it appear as if everything is synchronous.
A bit tongue-in-cheek, but is the runtime so bad at scheduling that this is necessary?
The Go runtime performance will be fine for most applications.
The README says a bit more about who the target audience is.
Yes, but that leaves the interesting question unanswered: Where is it doing better? Is it about reducing the goroutine stack usage?
At the end of the readme, there’s a benchmark.
Hm. So, from the benchmarks, it looks like they’re comparing to a goroutine spawn per IO operation. I should play around a bit to see how it compares if goroutines do more IO before exiting, or get reused.