[et1337]

I’m excited to see how this turns out. I work with Go every day and I think Io corrects a lot of its mistakes. One thing I am curious about is whether there is any plan for channels in Zig. In Go I often wish IO had been implemented via channels. It’s weird that there’s a select keyword in the language, but you can’t use it on sockets.

[jerf]

Wrapping every IO operation into a channel operation is fairly expensive. You can get an idea of how fast it would work now by just doing it, using a goroutine to feed a series of IO operations to some other goroutine.

It wouldn't be quite as bad as the perennial "I thought Go is fast why is it slow when I spawn a full goroutine and multiple channel operations to add two integers together a hundred million times" question, but it would still be a fairly expensive operation. See also the fact that Go had fairly sensible iteration semantics before the recent iteration support was added by doing a range across a channel... as long as you don't mind running a full channel operation and internal context switch for every single thing being iterated, which in fact quite a lot of us do mind.

(To optimize pure Python, one of the tricks is to ensure that you get the maximum value out of all of the relatively expensive individual operations Python does. For example, it's already handling exceptions on every opcode, so you could win in some cases by using exceptions cleverly to skip running some code selectively. Go channels are similar; they're relatively expensive, on the order of dozens of cycles, so you want to make sure you're getting sufficient value for that. You don't have to go super crazy, they're not like a millisecond per operation or something, but you do want to get value for the cost, by either moving non-trivial amount of work through them or by taking strong advantage of their many-to-many coordination capability. IO often involves moving around small byte slices, even perhaps one byte, and that's not good value for the cost. Moving kilobytes at a time through them is generally pretty decent value but not all IO looks like that and you don't want to write that into the IO spec directly.)

[Zambyte]

> One thing I am curious about is whether there is any plan for channels in Zig.

The Zig std.Io equivalent of Golang channels is std.Io.Queue[0]. You can do the equivalent of:

    type T interface{}

    fooChan := make(chan T)
    barChan := make(chan T)

    select {
    case foo := <- fooChan:
        // handle foo
    case bar := <- barChan:
        // handle bar
    }

in Zig like:

    const T = void;

    var foo_queue: std.Io.Queue(T) = undefined;
    var bar_queue: std.Io.Queue(T) = undefined;

    var get_foo = io.async(Io.Queue(T).getOne, .{ &foo_queue, io });
    defer get_foo.cancel(io) catch {};

    var get_bar = io.async(Io.Queue(T).getOne, .{ &bar_queue, io });
    defer get_bar.cancel(io) catch {};

    switch (try io.select(.{
        .foo = &get_foo,
        .bar = &get_bar,
    })) {
        .foo => |foo| {
            // handle foo
        },
        .bar => |bar| {
            // handle bar
        },
    }

Obviously not quite as ergonomic, but the trade off of being able to use any IO runtime, and to do this style of concurrency without a runtime garbage collector is really interesting.

[0] https://ziglang.org/documentation/master/std/#std.Io.Queue.

[ecshafer]

Have you tried Odin? Its a great language thats also a “better C” but takes more Go inspiration than Zig.

[dismalaf]

Second vote for Odin but with a small caveat.

Odin doesn't (and won't ever according to its creator) implement specific concurrency strategies. No async, coroutines, channels, fibers, etc... The creator sees concurrency strategy (as well as memory management) as something that's higher level than what he wants the language to be.

Which is fine by me, but I know lots of people are looking for "killer" features.

[thegeekpirate]

Completely replaced Go for me after using Go since inception.

Wonderful language!

[osigurdson]

At least Go didn't take the dark path of having async / await keywords. In C# that is a real nightmare and necessary to use sync over async anti-patterns unless willing to re-write everything. I'm glad Zig took this "colorless" approach.

[rowanG077]

Where do you think the Io parameter comes from? If you change some function to do something async and now suddenly you require an Io instance. I don't see the difference between having to modify the call tree to be async vs modifying the call tree to pass in an Io token.

[kbd]

One of the harms Go has done is to make people think its concurrency model is at all special. “Goroutines” are green threads and a “channel” is just a thread-safe queue, which Zig has in its stdlib https://ziglang.org/documentation/master/std/#std.Io.Queue

[jerf]

A channel is not just a thread-safe queue. It's a thread-safe queue that can be used in a select call. Select is the distinguishing feature, not the queuing. I don't know enough Zig to know whether you can write a bit of code that says "either pull from this queue or that queue when they are ready"; if so, then yes they are an adequate replacement, if not, no they are not.

Of course even if that exact queue is not itself selectable, you can still implement a Go channel with select capabilities in Zig. I'm sure one exists somewhere already. Go doesn't get access to any magic CPU opcodes that nobody else does. And languages (or libraries in languages where that is possible) can implement more capable "select" variants than Go ships with that can select on more types of things (although not necessarily for "free", depending on exactly what is involved). But it is more than a queue, which is also why Go channel operations are a bit to the expensive side, they're implementing more functionality than a simple queue.

[0x696C6961]

What other mainstream languages have pre-emptive green threads without function coloring? I can only think of Erlang.

[dlisboa]

It was special. CSP wasn't anywhere near the common vocabulary back in 2009. Channels provide a different way of handling synchronization.

Everything is "just another thing" if you ignore the advantage of abstraction.

[thiht]

What's the harm exactly?