6 ms·

I've been writing Zig since the beginning of the year. Just playing around with some small stuff really. I want to love the language. It does so much right, but

I've been writing Zig since the beginning of the year. Just playing around with some small stuff really. I want to love the language. It does so much right, but there's something about it just feels off to me. And then the recent Io change really bugged me.

olivia-banks 1y ago
I agree with the "off" part. I've thought maybe it's the syntax? It's unclear, but I'm just hoping the feeling will go away! I find the IO changes to be strange, it's almost as if Zig is encoding an effect system a-la Haskell (i.e. this function will have an allocation/IO side effect).
- bsder 1y ago
  > I find the IO changes to be strange Perhaps you just feel that way because of 10+ years of accreted expectations? To me, it feels like a reinvention of an interesting idea: Fastbufs https://www.ucw.cz/libucw/doc/ucw/fastbuf.html https://www.ucw.cz/libucw/doc/ucw/fastbuf.html I will concede that the ergonomics of Io in Zig right now are pretty rough sledding.
  - scuff3d 1y ago
    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.
    - bsder 1y ago
      > 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.
      - pjmlp 1y ago
        > Zig seems to be aiming to be a better C. 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.
      - scuff3d 1y ago
        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.
  - 0-R-1-0-N 1y ago
    Io as an interface isn’t released yet, I say wait and let’s try it out. Maybe it’s crap and something else will be implemented like the other previous async solutions in zig. Since zig isn’t a 1.0 lang yet it’s expected to have some pitfalls and breakage.
sothatsit 1y ago
I suspect a lot of this is due to the language being new and unpolished. Zig is still actively being shaped, and therefore fundamental pieces of the Zig standard library still change frequently. I really like Zig, but I do think you have to accept some rough edges and breaking changes when using it. Give it another decade and I am hopeful it will be much more stable.
- scuff3d 1y ago
  I agree, and I try to ignore that stuff, but there are a few things that I think are a little more fundamental then that. This one is fairly minor, but the overly granular namespacing drives me nuts. I shouldn't have to go four or five layers deep to get fairly common functionality. The pattern of returning structs from within structs from within structs just gets old. Maybe that has to do with the way the language handles generics, I don't know. The attitude to interfaces is also grating. I get that Kelly and the Zig team want to discourage there use, but with the changes to Io it feels a bit like they want to have their cake and eat it to. Before it was mainly just allocators, but now readers, writers, and it sounds like async are all going to be handled through interfaces. But yet the community writ large is still expected to not really use them. Seems like they should have sorted their attitude and approach to interfaces before making these most recent changes.
  - 0-R-1-0-N 1y ago
    Reader and writers were interfaces before 0.15.1. What’s new is that they are buffered. I don’t think that zig discourages interfaces, just that the language doesn’t hide anything. An interface in all system languages is a struct with a vtable just like in zig but that they have an easy way of creating one. If you need one in zig you can go that approach or use a tagged union just that zig is open about what an interface is.
    - scuff3d 1y ago
      Yes I know. I see the same statement every single time this conversation comes. Let me ask this: hypothetically if they wanted to, would it be possible for Zig to add a language feature called Interface which provided to the user "...an easy way of creating one".
deagle50 1y ago
I have the same feeling, and my best guess is that it's the intentional (and imo arbitrary) friction that has been sprinkled into the language. And camelCase.
- scuff3d 1y ago
  Lol. Funny enough I actually like camel case because I've spent so much time in Java. Yeah, I can see that. It's also difficult to put my finger on, but for a language that claims to be simple it seems to make a lot of things needlessly complicated. I'm also not loving how everything is deeply nested structs so I have to do struct.doThefirstThing.doTheSecondThing.doTheThirdThing().etc() all the time.

olivia-banks 1y ago

I agree with the "off" part. I've thought maybe it's the syntax? It's unclear, but I'm just hoping the feeling will go away! I find the IO changes to be strange, it's almost as if Zig is encoding an effect system a-la Haskell (i.e. this function will have an allocation/IO side effect).

bsder 1y ago
> I find the IO changes to be strange Perhaps you just feel that way because of 10+ years of accreted expectations? To me, it feels like a reinvention of an interesting idea: Fastbufs https://www.ucw.cz/libucw/doc/ucw/fastbuf.html https://www.ucw.cz/libucw/doc/ucw/fastbuf.html I will concede that the ergonomics of Io in Zig right now are pretty rough sledding.
- scuff3d 1y ago
  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.
  - bsder 1y ago
    > 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.
    - pjmlp 1y ago
      > Zig seems to be aiming to be a better C. 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.
    - scuff3d 1y ago
      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.
- 0-R-1-0-N 1y ago
  Io as an interface isn’t released yet, I say wait and let’s try it out. Maybe it’s crap and something else will be implemented like the other previous async solutions in zig. Since zig isn’t a 1.0 lang yet it’s expected to have some pitfalls and breakage.

sothatsit 1y ago

I suspect a lot of this is due to the language being new and unpolished. Zig is still actively being shaped, and therefore fundamental pieces of the Zig standard library still change frequently. I really like Zig, but I do think you have to accept some rough edges and breaking changes when using it. Give it another decade and I am hopeful it will be much more stable.

scuff3d 1y ago
I agree, and I try to ignore that stuff, but there are a few things that I think are a little more fundamental then that. This one is fairly minor, but the overly granular namespacing drives me nuts. I shouldn't have to go four or five layers deep to get fairly common functionality. The pattern of returning structs from within structs from within structs just gets old. Maybe that has to do with the way the language handles generics, I don't know. The attitude to interfaces is also grating. I get that Kelly and the Zig team want to discourage there use, but with the changes to Io it feels a bit like they want to have their cake and eat it to. Before it was mainly just allocators, but now readers, writers, and it sounds like async are all going to be handled through interfaces. But yet the community writ large is still expected to not really use them. Seems like they should have sorted their attitude and approach to interfaces before making these most recent changes.
- 0-R-1-0-N 1y ago
  Reader and writers were interfaces before 0.15.1. What’s new is that they are buffered. I don’t think that zig discourages interfaces, just that the language doesn’t hide anything. An interface in all system languages is a struct with a vtable just like in zig but that they have an easy way of creating one. If you need one in zig you can go that approach or use a tagged union just that zig is open about what an interface is.
  - scuff3d 1y ago
    Yes I know. I see the same statement every single time this conversation comes. Let me ask this: hypothetically if they wanted to, would it be possible for Zig to add a language feature called Interface which provided to the user "...an easy way of creating one".

deagle50 1y ago

I have the same feeling, and my best guess is that it's the intentional (and imo arbitrary) friction that has been sprinkled into the language. And camelCase.

scuff3d 1y ago
Lol. Funny enough I actually like camel case because I've spent so much time in Java. Yeah, I can see that. It's also difficult to put my finger on, but for a language that claims to be simple it seems to make a lot of things needlessly complicated. I'm also not loving how everything is deeply nested structs so I have to do struct.doThefirstThing.doTheSecondThing.doTheThirdThing().etc() all the time.