The author also livestreams (I believe on twitch) and publish VODs on youtube, showcasing new features, updates and whatnot!
I'm quite enjoying watching progress updates, relevant examples and Q&A :)
Zig 0.5.0 Release Notes
41–50 of 80 posts
Re: Zig 0.5.0 Release Notes
#42> Speaking of performance, Zig is faster than C. These kinds of claims make me so dubious for a language. Also who is trying to switch from C to get an ever-so-slightly performance improvement? That use-case goes to specialized hardware such as FPGAs.
You picked that quote from the main page, not from the release notes, here is what directly follows: * The reference implementation uses LLVM as a backend for state of the art optimizations. * What other projects call "Link Time Optimization" Zig does automatically. * For native targets, advanced CPU features are enabled (-march=native), thanks to the fact that Cross-compiling is a first-class use case. * Carefully c…
> For example, in Zig both signed and unsigned integers have undefined behavior on overflow, contrasted to only signed integers in C.
Huh, that's a strange choice. What's the safety story for Zig? Are these always undefined, or is that only in an "unchecked" build?
Re: Zig 0.5.0 Release Notes
#43Earlier quoted context omitted.
Yeah, I always check that. The part that says "There is no stdlib documentation yet, but it is planned for the next release" links to a 2015 github issue. That's why I was wondering if it's still a priority or if there were still high level concerns about stability/curation/etc preventing docs from being written.
It's an unwillingness to implement documentation generation twice. Why do it in the c++ compiler when the goal is to become self-hosted? I think there's a good answer to this which is, "because people really, really need documentation." So I am kicking around ideas of how this can be done without too much duplicate effort.
Couldn’t you say this about every single feature implemented in the C++ compiler?
Re: Zig 0.5.0 Release Notes
#44The author also livestreams (I believe on twitch) and publish VODs on youtube, showcasing new features, updates and whatnot! I'm quite enjoying watching progress updates, relevant examples and Q&A :)
The streams are on Twitch: https://www.twitch.tv/andrewrok
Re: Zig 0.5.0 Release Notes
#45It's an exciting week for programming languages. First Nim, then Zig. Keep up the great work!
Does anyone here have a good understanding of the relative merits of Zig, Crystal, and Nim? Especially compared to higher profile languages like Rust and Go? All of these languages seem to be statically compiled, and they all seem to promise both performance and safety. Rust and Go are discussed all the time on HN, so I expect most of us here have a reasonable notion of their relative benefits, for example, performan…
Zig and Rust both don't have a runtime/GC, they should be on par with performance in C, meaning they are slightly faster than the others (of course this all depends). Go is the only one you listed that doesn't have some kind of parametric polymorphism support (generics). Rust is the only one that will validate your program is memory safe at compile time, they call this 'data race freedom'.
I think in the end it's really up to your tastes which you prefer. Have a look at the tenets of each of the languages and see which resonates with you.
Re: Zig 0.5.0 Release Notes
#46Earlier quoted context omitted.
You picked that quote from the main page, not from the release notes, here is what directly follows: * The reference implementation uses LLVM as a backend for state of the art optimizations. * What other projects call "Link Time Optimization" Zig does automatically. * For native targets, advanced CPU features are enabled (-march=native), thanks to the fact that Cross-compiling is a first-class use case. * Carefully c…
> For example, in Zig both signed and unsigned integers have undefined behavior on overflow, contrasted to only signed integers in C. Huh, that's a strange choice. What's the safety story for Zig? Are these always undefined, or is that only in an "unchecked" build?
The latter. Zig actually kinda does define this behavior as "`a + b` shall not overflow" and inserts checks in debug and safe builds for it. To get overflow, which zig defines as wrapping overflow, you use a different operator and no check is inserted "`a +% b`". For speed optimized builds, unless you've explicitly told the compiler to insert checks in that scope, it will turn the checks into nops.
So, while it is technically correct to say that it has undefined behavior for overflow, the practical reality is quite different.
Re: Zig 0.5.0 Release Notes
#47It's an exciting week for programming languages. First Nim, then Zig. Keep up the great work!
Does anyone here have a good understanding of the relative merits of Zig, Crystal, and Nim? Especially compared to higher profile languages like Rust and Go? All of these languages seem to be statically compiled, and they all seem to promise both performance and safety. Rust and Go are discussed all the time on HN, so I expect most of us here have a reasonable notion of their relative benefits, for example, performan…
Re: Zig 0.5.0 Release Notes
#48I might be alone with this thought: Zig seemed really appealing in the beginning, but now I dislike it more and more with each release. It does not seem to keep the simplicity of C at all, it has lots of peculiarities, and it is becoming more and more bloated. I would consider it a C++ replacement at this point, not a C replacement due to its increasing complexity. One of Zig's philosophy was simplicity[1], but I do…
I do get the feeling, but I think part of it is simply that those of us that are used to C tend to underestimate its complexity. Especially when you consider various extensions which are widely used, the preprocessor magic often needed to perform essential tasks, and all the undefined behaviour.
There is really only one thing that I would say goes beyond keeping the language simple as possible: the async stuff. But I think it will probably be totally worth it. The async implementation looks a lot more elegant than anything I've seen so far, and it could be extremely useful in the embedded world, which is one of the places where C is dominant. It might make the language a bit more complicated, but it will make the resulting code much more simpler for a lot of applications, without compromising other goals like safety and efficiency.
Zig is still much, much closer to C than C++. If you don't think so, then you're vastly underestimating the complexity of C++.
Re: Zig 0.5.0 Release Notes
#49Looks promising.
Can we have a consistent function notation
fn name(a: int, b: int) -> void {}
This also helps with clean functional type arguments.
swift and rust support this.
A single consistent notation will be helpful for new polyglots.
Re: Zig 0.5.0 Release Notes
#50Earlier quoted context omitted.
Could you follow up with some examples? Seems to contradict the parent but neither comment provides examples.
They got rid of the % operator for error propagation for one.
That's funny; one selling point of rust is the easy propagation of errors thanks to the '?' but zig removed the % which was the equivalent I think