Is there a decent native GUI library for Zig yet? I don't want to use bloated toolkits like GTK and Qt.
I like the simplicity and speed of Rust's eGUI. Something similar for Zig would be amazing.
Why is Zig so cool?
61–70 of 527 posts
Re: Why is Zig so cool?
#62[deleted]
Re: Why is Zig so cool?
#63> I can’t think of any other language in my 45 years long career that surprised more than Zig. I can say the same (although my career spans only 30 years), or, more accurately, that it's one of the few languages that surprised me most. Coming to it from a language design perspective, what surprised me is just how far partial evaluation can be taken. While strictly weaker than AST macros in expressive power (macros ar…
I agree. I look forward to a future high-level language that uses something like comptime for metaprogramming/interfaces/etc, is strongly typed, but lets you write scripts as easily as python or javascript.
perhaps mojo might be your cup of tea ?
Re: Why is Zig so cool?
#64What is Zig?
what comes before Zag ?
Re: Why is Zig so cool?
#65For a language that’s so low level and performance focused, I’m surprised that it has those extra io and allocator arguments to functions. Isn’t that creating code bloat and runtime overhead?
io and allocator objects each only contain 4 pointers or so. They are very fast to wire up and don't create much overhead at all.
Re: Why is Zig so cool?
#66For a language that’s so low level and performance focused, I’m surprised that it has those extra io and allocator arguments to functions. Isn’t that creating code bloat and runtime overhead?
Regarding runtime overhead, I'd assume you would still need an io implementation, it is just showing it to you explicitly instead of it being hidden behind the std lib. For simple projects where you don't want to pass it around in function parameters, you can create a global object with one implementation and use it from everywhere.
Yeah thing is it's usually better to have allocator in particular defined as a parameter so that you can use the testing allocator in your tests to detect memory leaks, double frees, etc. And then you use more optimal allocators for release mode.
Re: Why is Zig so cool?
#67A neat little thing I like about Zig is one of the options for installing it is via PyPI like this: https://pypi.org/project/ziglang/ pip install ziglang Which means you don't even have to install it separately to try it out via uvx. If you have uv installed already try this: cd /tmp echo '#include int main() { printf("Hello, World!"); return 0; }' > hello.c uvx --from ziglang python-zig cc /tmp/hello.c ./a.out
reinventing nix but worse.
Re: Why is Zig so cool?
#68There's at least 1 thing that Zig is better than Rust is that Zig compiler for Windows can be downloaded, unzipped then used without admin right. Rust needs msvc, which cannot be installed without admin right. It is said that Rust on Windows can use cygwin but I cannot make it work even with AI help.
Have you tried the GNU toolchain? IIRC rustup provides the option to use it instead of the MSVC toolchain during the initial installation.
Re: Why is Zig so cool?
#69Is it cool? It seems to be in nether land between Rust and Go. Not sure what is the unique use case for Zig.
It's more of an in-between C and Rust than Go as it is a systems language with no built-in garbage collector for memory management. It has a lot of memory safety features, but it's not as memory safe as Rust. However, it avoids a lot of the complexity of Rust like implicit macro expansion, managing lifetimes, generics and complex trait system, etc. It also compiles much more compactly than Rust, in my experience.
In my mind, it's an accessible systems language. Very readable. Minimal footprint.
Re: Why is Zig so cool?
#70In my opinion the biggest issue of Zig is that it doesn't allow attaching data to error. The error can only be passed via side channel, which is inconvenient and ENOURAGES TOOL DEVELOPERS TO NOT PASS ERROR DATA, which greatly increase debugging difficulty.
Somethings there are 100 things that possibly go wrong. With error data you can easily know which exact thing is wrong. But with error code you just know "something is wrong, don't know which exactly".
See: https://github.com/ziglang/zig/issues/2647#issuecomment-1444...
> I just spent way longer than I should have to debugging an issue of my project's build not working on Windows given that all I had to work with from the zig compiler was an error: AccessDenied and the build command that failed. When I finally gave up and switched to rewriting and then debugging things through Node the error that it returned was EBUSY and the specific path in question that Windows considered to be busy, which made the problem actually tractable ... I think the fact that even the compiler can't consistently implement this pattern points to it perhaps being too manual/tedious/unergonomic/difficult to expect the Zig ecosystem at large to do the same