21–30 of 51 posts
I don't really have much interest in Zig the language, but Zig as a standalone C/C++ compiler is pretty great. I'm using it as a cross-compiler for linux-arm64 because its much simpler to download a single archive and extract it somewhere than to waste a bunch of time on guessing how each different Linux distro does ARM64 cross compilers (or doesn't in the case of Fedora).
Earlier quoted context omitted.
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.
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.
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.
Earlier quoted context omitted.
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).
> 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 I will concede that the ergonomics of Io in Zig right now are pretty rough sledding.
The more I hear about Zig, the more I appreciate it. Its vertically integrated stack (with the custom linker and code-generation backends) stands out to me as a really compelling feature that enables interesting optimizations. The compiler is also much easier to interact with in a consistent way compared to C. I've been using it as an experimental backend for my language project with great results.
One annoyance that I've ran into when using Zig as a transpiler backend is the lack of unstructured goto. Many languages don't need that, but if you're dealing with the one that does, converting such code is non-trivial.
The more I hear about Zig, the more I appreciate it. Its vertically integrated stack (with the custom linker and code-generation backends) stands out to me as a really compelling feature that enables interesting optimizations. The compiler is also much easier to interact with in a consistent way compared to C. I've been using it as an experimental backend for my language project with great results.
> I've been using it as an experimental backend for my language project with great results. One annoyance that I've ran into when using Zig as a transpiler backend is the lack of unstructured goto. Many languages don't need that, but if you're dealing with the one that does, converting such code is non-trivial.
Eventually, I restructured my IR to allow for more imperative code-generation, which I believe will lead to slightly better optimizations by the compiler.
Earlier quoted context omitted.
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.
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 h…
Just going to mention the book Linkers and Loaders by John R. Levine, I'm not sure if there's anything comparable to it.
Earlier quoted context omitted.
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).
> 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 I will concede that the ergonomics of Io in Zig right now are pretty rough sledding.
Earlier quoted context omitted.
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 h…
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 inter…
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".