I said this elsewhere, but I think the awkwardness is coming from Zigs attitude towards interfaces. It seems like from a language design perspective they've been made intentionally awkward because they want to discourage their use, and fair enough. There are other options for sure. But now they want to base Io around interfaces. So Writers and Readers, it sounds like Async as well, and of course Allocators were already using interfaces. If they are going to become that fundamental to core features of the language, I think a more ergonomic way to work them needs to be a higher priority.
> It seems like from a language design perspective they've been made intentionally awkward
Awkward relative to what?
Relative to C? Did you look at my link to Fastbufs? Take a look at that and then get back to me how awkward Zig is relative to that.
Zig seems to be aiming to be a better C. Full stop. If you want abstraction, RAII and other higher-level stuff, C++ and Rust exist.
> If they are going to become that fundamental to core features of the language, I think a more ergonomic way to work them needs to be a higher priority.
I don't disagree. However, there have really only been two times so far that significant "interfaces" have churned like this (Allocgate and Writergate). Allocgate was driven by the fact that the previous implementation had real, measurable performance issues. Presumably, Writergate is being driven by similar problems. I'm actually really happy that someone is designing a language while paying very strict attention to the performance of both the compiler and the compiled code.
It's really hard to generalize until you get a couple of concrete examples under your belt. Trying to make an "interface" more ergonomic when it may get nuked from orbit in a couple of versions is kind of pointless.
I have plenty of gripes about Zig, but "interface churn" or "ergonomics" aren't very high on my list. I signed up for a language that is pre-1.0, so, while I may get annoyed, I also have to admit that I did this to myself.
Modula-2 and Object Pascal already did that for me, before I cared with C on MS-DOS, unfortunely one did not come with UNIX as selling point, and the other had the two industry giants that cared doing the wrong decisions.
In general I agree with you, Zig is obviously trying to give as much control as possible and avoid higher level abstractions, but it's not like they haven't added elements to the language to improve ergonomics and make the right choice the easy choice.
For loops with a capture group. Under the hood Zig is doing bounds checking and binding the result of each iteration to the variable in the capture groups.You can add a range to that and Zig will iterate it for you. One could argue this is a "higher level" abstractation compared to a traditional for loop and accessing an array by index, but it exists because it naturally pushes developers to write more robust code.
The try keyword, being short hand for catch err return err. A Go developer might argue that it's better to be explicit and not have try. But it's a common pattern and it's far more ergonomic to use the try keyword then it is to catch and return every single time.
Shit, you could argue that the entire idea of comp time is an abstraction to allow code generation. Someone like Ginger Bill would argue you're better off writing a separate program to generate source code then use meta programming.
With the upcoming IO interface and the plans for async, it seems to me that interfaces are going to play a much more prominent role in the language. It makes sense they might want to consider abstractions that push developers towards good design when working with them.
