[willvarfar]

The benchmarks at the bottom of the readme show quite an improvement (with a single thread it seems).

I would speculate the performance win is because there is no stack switching and less channels.

I've done lots of event loops in the past (eg hellepoll in c++) and think that the cost of that is on the programmer - keeping track of things, callbacks, state machines and things and avoiding using the stack for state etc is all hard work and easy to mess up.

I am reminded of this post I saw on HN a while ago https://www.mappingthejourney.com/single-post/2017/08/31/epi... Ryan Dahl, creator of node.js, would just use Go today ;)

[Acconut]

> I've done lots of event loops in the past (eg hellepoll in c++) and think that the cost of that is on the programmer - keeping track of things, callbacks, state machines and things and avoiding using the stack for state etc is all hard work and easy to mess up.

I very much agree. In the past, I have had quite some fun developing a few streaming parsers using Node.js, which also uses an event loop. And while these parser worked relatively good and efficient, debugging them was not an easy task. In addition, understanding the code is also a though challenge, especially for people other than the original authors.

When I started using Go more and more, I really enjoyed the different I/O-model using goroutines and blocking function calls. It also has a few drawbacks but the mental model is a lot easier to reason about.

[nly]

> I've done lots of event loops in the past (eg hellepoll in c++) and think that the cost of that is on the programmer - keeping track of things, callbacks, state machines and things and avoiding using the stack for state etc is all hard work and easy to mess up.

This is improving, even in C++. This is what the core loop of a line-based echo server could look like in C++17 (and something very similar compiles today on my machine)

    void echo_loop (tcp::socket socket) {
        io::streambuf buffer;
        std::string line;
        std::error_code ec;
        do {
            ec = co_await async_read_line (socket, buffer, line);
            if (ec)
                break;
            ec = co_await async_write (socket, line);
        } while (!ec);
    }

[tidwall]

Wow. That looks really simple.

[nly]

Unfortunately it's just exposition, but here[0] is a version that works with Clang 5 + Boost

Echo specific code starts on line 167. Everything above will hopefully be provided by the standard library once both the Networking TS and Coroutine TS merge in to C++20.

One nice thing about lines 1 - 165 though, is that it demonstrates how easy it is to extend the native coroutine capabilities in C++ to support arbitrary async libraries, even if the author of those libraries didn't know anything about coroutines. All this happens without breaking the ability to call these coroutines from C. You can even use async C libraries that only provide a void* argument to your callback.

[0] https://gist.github.com/anonymous/d9a258136431a352516122d1c9...

[striking]

Yeah, but that's with 1 maximum thread. The whole point of Go is to use green threading to your advantage.

[tidwall]

While goroutines are cool, there's not the whole point of Go for me.