1. 10

  2. 4

    I’ve been waiting for something this to appear. Green threads are convenient, but sometimes you really want to step outside the event loop.

    1. 4

      I have 2 problems with this.

      1. Event loop code for me is annoying to write, but if people like it, I guess it is no big deal to them.
      2. One of the strengths of Go is all the code follows the same ‘model’ of control flow etc, so most libraries interoperate really well. Using this breaks that and fractures library writers.
      1. 2

        I think it could be reasonably easy to write an “adapter” to allow normal go libraries to consume a normal net.Conn while still keeping the performance of the event loop networking, probably with some buffering to prevent blocking accesses…

        I don’t think there will be much fracturing, the default go model is very popular and will probably remain such.

      Stories with similar links:

      1. evio: kqueue/epoll-based async networking for Go via eatonphil 5 months ago | 5 points | 5 comments