1. 5

  2. 5

    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?

    1. 2

      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.

      1. 1

        Yes, but that leaves the interesting question unanswered: Where is it doing better? Is it about reducing the goroutine stack usage?

        1. 1

          At the end of the readme, there’s a benchmark.

          1. 1

            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.

    Stories with similar links:

    1. Fast event loop networking for Go via st3fan 3 years ago | 10 points | 3 comments