11 ms·

This article praises everything Zig does and lists no negatives of its design. I'd recommend a different article for a balanced take, particularly regarding com

by an_ko 4y ago

This article praises everything Zig does and lists no negatives of its design. I'd recommend a different article for a balanced take, particularly regarding comparisons with Rust: https://www.scattered-thoughts.net/writing/assorted-thoughts-on-zig-and-rust/ https://www.scattered-thoughts.net/writing/assorted-thoughts...

wzwy 4y ago
That’s what I felt as well when I read it. Maybe it’s as industry-redefining as it claims to be, but surely there must be some tradeoffs. Rust’s tradeoff in providing safe and faster code is mentioned. Why not Zig’s?
- socialdemocrat 4y ago
  Having played with Zig I would say the tradeoff is complexity. Zig is harder to learn than C with more difficult concepts. Something like Go is much quicker. Yet I think Zig is finding an okay balance. You can still get productive much faster than in Rust. Manual memory management gives obvious downsides which should be well known. Zig does this in the best way I have seen though.
  - ikskuh 4y ago
    > Zig is harder to learn than C with more difficult concepts. I'm using Zig and C for a good amount of time now and i disagree. Zig has simpler concepts as C, but in C you can just ignore them. Consider char buf[4]; float * f = buf; *f = 32; Seems simple, compiles, and even executes. Everyone is happy. But that code will just explode randomly on non-x86 platforms as it violates alignment rules. In Zig, this code will give you a compile error, as []u8 does have alignment 1, while a []f32 will have alignment 4. This means you have to learn about alignment before accidently writing code that will randomly crash at runtime depending on the stack position of buf. And Zig has a lot of these things that require implicit knowledge in C as explicit knowledge implemented in the language itself. Same goes for integer casting, shifting more than sizeof() bits, and so on. It moves the footguns from the code to the user, and so the user has to learn about all of these concepts before writing Zig code. In C, the code will silently compile and misbehave at runtime. This might feel like additional complexity in a lot of places, but the complexity is there in both languages. One just makes it explicit. But this is obviously not true for all things in Zig. comptime is a whole new feature that wasn't seen in a lot of languages before and afaik not as it is used in Zig, so it's something new to learn even if you already can do perfect C. The same goes for more precise data types (struct vs extern struct) and so on. One hard footgun in Zig right now is implicit aliasing of parameter types, which sometimes get passed as a reference and sometimes as a value. This is a known footgun is already on the table to be adressed by better semantics and more safety guards For me, writing Zig feels way less complex than C because a lot of brain load that went into writing correct C was offloaded to the compiler, which is good. But it also increases the friction when writing code as the compiler forces you to think about alignment and such.
dafneee 4y ago
>we can't type-check zig libraries which contain generics. >comptime is_odd_perfect_number(n) I assume zig has a finite bound on comptime_int, so we can in fact always know what is_odd_perfect_number() returns.
- andrepd 4y ago
  You misunderstand. > we can't type-check zig libraries which contain generics. We can only type-check specific uses of those libraries. I.e. you cannot say whether this compiles for all n, only for the instances you actually instantiate
  - littlestymaar 4y ago
    Right, and this should be discussed a lot more when talking about Zig, because I suspect this is going to be a significant burden at the ecosystem level: - library users will find compilation errors in the library code (his is annoying, but when you get used to it, you can treat it as any kind of library bugs and submit a PR) - library users are going to rely on accidental behaviors (that is “in the library author's mind this isn't been used this way”) and then you'll have breaking changes without noticing. (I say that as someone currently working on a DSL for the train industry, and this language (started in 2012) has something really close to Zig's comptime and we're currently trying to move away from it, because of the aforementioned issues. And it's actually pretty hard because big chunks of the existing code don't actually compile unconditionally and only compile when a given set of compile-time conditions are met, which makes the migration process hard)
    - verdagon 4y ago
      I suspect this might not be a problem for Zig long-term. One can imagine a blend of comptime, concepts, and generics which which can help mitigate (and often solve) these kinds of problems. When combined with compiler enforcement (or even a community-adopted linter) this could help the library author detect problems while still being able to use comptime's unique benefits.
    - 4y ago
Ygg2 4y ago
Well, yeah the article is meant to promote it. They had podcast and everything. Same with Rust podcast.
- tialaramex 4y ago
  Yes, I think we should understand that this is what Andrew says, so e.g. "This type of optimization, Andrew explains, would not be possible in languages like Rust" is akin to when football players tell you they're confident they can win. Of course they're confident they can win, but at least half of them are going to be disappointed. I actually don't know what Andrew is getting at with that particular case though. If the situation is that the types are obvious, so the Zig isn't ever looking at the tags, the Rust won't look at the tags either. Worse, I don't think Zig has niche optimisation, so there are a bunch of cases where Zig has to choose, have tags (more space, slower, but same safety as Rust) or go without (same size as Rust, but less safety). Rust only guarantees the niche in certain narrow cases like Option<&T> (is the same size as &T) but it actually delivers a lot more than that, and this continues to improve.
openfuture 4y ago
Well zig could be a no tradeoff improvement over C while rust definitely has tradeoffs. So I think "all good" is a plausible assessment.
- steveklabnik 4y ago
  Everything has tradeoffs. Be careful, lest the "Zig Evangelism Strike Force" becomes a thing!
  - deleted 4y ago
    [deleted]
- sakras 4y ago
  A bit pedantic, but a trade off with any new programming language is “having to learn a new language”. I haven’t programmed in zig but the syntax looks different enough from C that it would take a while to pick up.
xorvoid 4y ago
This 100% I’m darn sick of reading articles that don’t consider tradeoffs. Engineering can be defined as “a search for the optimal set of tradeoffs”. But, it seems like every article I ever read about new tech only discussed pros, not cons. I don’t get it. The cons are just as important, if not more so. Unfortunately, for some reason, people associate cons with flaws/weaknesses/failures rather than just a “point on the tradeoff curve”. Often: no perfect solution exists and those claiming otherwise are being dishonest. I would love to see this culture change at least for engineering literature where we should know better. All that said: I DO think that Zig has selected a reasonable point in the tradeoff curve. I just really want to understand that point better. How am I supposed to use it most effectively if I don’t understand it?
- bsder 4y ago
  Here is the question I think that you need to answer to choose between Rust and Zig: If your dependencies wrap more than 2 external libraries that have poor architecture, you're about to have a miserable time in Rust. Rust creates a lot of friction if an external library has a poor architecture. And, by default, most libraries have a very poor architecture. This leads to things like: "Giving up on wlroots-rs"--http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-in-c.html http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i... Talk about the issues of RLua--https://www.reddit.com/r/rust/comments/biq864/giving_up_on_wlrootsrs/ https://www.reddit.com/r/rust/comments/biq864/giving_up_on_w... "The thing that was SO tiring about writing this for me wasn't Rust, it was reasoning about the C library that I was binding. I'm just... tired of using C APIs! I'm tired of not having the compiler reason for me, I'm tired of having to second guess at what invariants the API expects and guess at what of a myriad of interesting non-local behavior a function call will do. I know that the Lua C API is a really, especially bad example, but I just don't know what the general solution is here." Consequently, this is where you get "Rewrite All The Things In Rust!" What's the point of fighting with Rust over all these nice safety guarantees and then throwing them out at the API boundary? If you can keep everything in Rust, this simply isn't an issue. This is where Zig shines. It catches some of the main classes of bugs but still lets you talk to libraries with crap architecture. Zig gets the fact that infrastructure and ecosystem matter--unlike everybody else operating in the C space (the cross compiling is phenomenal, for example, because they put a lot of work into it). Zig is doing some interesting things, but it's mostly some very solid choices with a lot of elbow grease applied. And that's worth a LOT. As an aside, I will also say that Zig feels better for embedded programming than Rust. Rust feels like it has stalled in embedded areas (things like sized integers, bitfield packing, placement construction of data structures, statics and globals that don't have locking overhead, lack of do-while, etc. although I would like to point out in Rust's favor that Rust finally got label-break-value which is a godsend when porting embedded code with goto error handling) while Zig has explicitly targeted those from the beginning. That makes Zig feel better for embedded from an ergonomic perspective, to my (obviously quite subjective) taste.
karmakaze 4y ago
I watched the video rather than read the short post. It did a good job getting into details that illustrate some of the tradeoffs. e.g. Do you want a small language that you can fully learn, or do you want a language with many features that you can spend time learning? Other things that are made explicit such as specifying an allocator on every allocation is an inconvenience that you pay for that flexibility. The choice of safety being added rather than assumed and later satisfied or declared an unsafe area is vastly different with a tradeoff in how developers use the language. An example given was how the self-hosted complier can use cache optimized untagged unions with the tags in a separate array. If I had to guess what the single biggest pattern of tradeoffs is, I'd say it's about being explicit rather than implicit. You gain fine-grained control at the cost of brevity/convenience.
naikrovek 4y ago
I don't trust any language comparison one-on-one with Rust, because fans of Rust today are just like fans of Python 20 years ago: "this language is the greatest accomplishment of humanity, easily," if I had to sum up the vibe I'm talking about. compare [language] with C, fairly and accurately, if you want me to believe a word you say.
- kaba0 4y ago
  There is not many languages that would fair worse next to C. For starters, not being able to create any form of even minimal, zero-cost abstractions like a vector is criminal.
  - naikrovek 4y ago
    I think it's an apt comparison, Zig vs. C, given that Zig intends to replace C. Go was aiming to be a replacement for C as well, but they didn't even try to reach that goal because Go programs require an OS to run on; something must host the runtime, even though it's included in the binary. I love Go and I dislike C quite a bit. Zig vs. C seems fair to me, because there are no Zig zealots (or very few, at least not yet) and there are no C zealots who have lots of experience with C.
- deleted 4y ago
  [deleted]
- Yoric 4y ago
  That's funny, I read this affirmation (and variants thereof) rather often, but I've been using Rust on and off since 0.4 and I've always been discussing with developers who have balanced and careful opinions of Rust, starting with the Rust language and compiler teams. Rust has never been publicized as a solution to all problems. It happens to be my current favorite language for many tasks, but I don't think any serious Rust developer harbors the impression that Rust is designed to implement everything. That being said, the community is much larger these days, so I assume that there are users who do not have a sufficient PL background to understand the tradeoffs made in the design of Rust.
dingdingdang 4y ago
No standard utf8 string library is scary - I would happily learn all the mem gymnastics to make this work but fiddling with competing UTF8 libraries as is the case with C/C++ is just not my cuppa.
- deleted 4y ago
  [deleted]
- anonymoushn 4y ago
  There are functions for handling utf8 in the standard library.
  - dingdingdang 4y ago
    Well, there's functions for working with code points within the bytes that (may) make up utf8 strings.. in order to do actual string level manipulation a library is needed (such as https://github.com/jecolon/ziglyph https://github.com/jecolon/ziglyph or others)

by an_ko 4y ago

wzwy 4y ago

That’s what I felt as well when I read it. Maybe it’s as industry-redefining as it claims to be, but surely there must be some tradeoffs. Rust’s tradeoff in providing safe and faster code is mentioned. Why not Zig’s?

socialdemocrat 4y ago
Having played with Zig I would say the tradeoff is complexity. Zig is harder to learn than C with more difficult concepts. Something like Go is much quicker. Yet I think Zig is finding an okay balance. You can still get productive much faster than in Rust. Manual memory management gives obvious downsides which should be well known. Zig does this in the best way I have seen though.
- ikskuh 4y ago
  > Zig is harder to learn than C with more difficult concepts. I'm using Zig and C for a good amount of time now and i disagree. Zig has simpler concepts as C, but in C you can just ignore them. Consider char buf[4]; float * f = buf; *f = 32; Seems simple, compiles, and even executes. Everyone is happy. But that code will just explode randomly on non-x86 platforms as it violates alignment rules. In Zig, this code will give you a compile error, as []u8 does have alignment 1, while a []f32 will have alignment 4. This means you have to learn about alignment before accidently writing code that will randomly crash at runtime depending on the stack position of buf. And Zig has a lot of these things that require implicit knowledge in C as explicit knowledge implemented in the language itself. Same goes for integer casting, shifting more than sizeof() bits, and so on. It moves the footguns from the code to the user, and so the user has to learn about all of these concepts before writing Zig code. In C, the code will silently compile and misbehave at runtime. This might feel like additional complexity in a lot of places, but the complexity is there in both languages. One just makes it explicit. But this is obviously not true for all things in Zig. comptime is a whole new feature that wasn't seen in a lot of languages before and afaik not as it is used in Zig, so it's something new to learn even if you already can do perfect C. The same goes for more precise data types (struct vs extern struct) and so on. One hard footgun in Zig right now is implicit aliasing of parameter types, which sometimes get passed as a reference and sometimes as a value. This is a known footgun is already on the table to be adressed by better semantics and more safety guards For me, writing Zig feels way less complex than C because a lot of brain load that went into writing correct C was offloaded to the compiler, which is good. But it also increases the friction when writing code as the compiler forces you to think about alignment and such.

dafneee 4y ago

>we can't type-check zig libraries which contain generics. >comptime is_odd_perfect_number(n) I assume zig has a finite bound on comptime_int, so we can in fact always know what is_odd_perfect_number() returns.

andrepd 4y ago
You misunderstand. > we can't type-check zig libraries which contain generics. We can only type-check specific uses of those libraries. I.e. you cannot say whether this compiles for all n, only for the instances you actually instantiate
- littlestymaar 4y ago
  Right, and this should be discussed a lot more when talking about Zig, because I suspect this is going to be a significant burden at the ecosystem level: - library users will find compilation errors in the library code (his is annoying, but when you get used to it, you can treat it as any kind of library bugs and submit a PR) - library users are going to rely on accidental behaviors (that is “in the library author's mind this isn't been used this way”) and then you'll have breaking changes without noticing. (I say that as someone currently working on a DSL for the train industry, and this language (started in 2012) has something really close to Zig's comptime and we're currently trying to move away from it, because of the aforementioned issues. And it's actually pretty hard because big chunks of the existing code don't actually compile unconditionally and only compile when a given set of compile-time conditions are met, which makes the migration process hard)
  - verdagon 4y ago
    I suspect this might not be a problem for Zig long-term. One can imagine a blend of comptime, concepts, and generics which which can help mitigate (and often solve) these kinds of problems. When combined with compiler enforcement (or even a community-adopted linter) this could help the library author detect problems while still being able to use comptime's unique benefits.
  - 4y ago

Ygg2 4y ago

Well, yeah the article is meant to promote it. They had podcast and everything. Same with Rust podcast.

tialaramex 4y ago
Yes, I think we should understand that this is what Andrew says, so e.g. "This type of optimization, Andrew explains, would not be possible in languages like Rust" is akin to when football players tell you they're confident they can win. Of course they're confident they can win, but at least half of them are going to be disappointed. I actually don't know what Andrew is getting at with that particular case though. If the situation is that the types are obvious, so the Zig isn't ever looking at the tags, the Rust won't look at the tags either. Worse, I don't think Zig has niche optimisation, so there are a bunch of cases where Zig has to choose, have tags (more space, slower, but same safety as Rust) or go without (same size as Rust, but less safety). Rust only guarantees the niche in certain narrow cases like Option<&T> (is the same size as &T) but it actually delivers a lot more than that, and this continues to improve.

openfuture 4y ago

Well zig could be a no tradeoff improvement over C while rust definitely has tradeoffs. So I think "all good" is a plausible assessment.

steveklabnik 4y ago
Everything has tradeoffs. Be careful, lest the "Zig Evangelism Strike Force" becomes a thing!
- deleted 4y ago
  [deleted]
sakras 4y ago
A bit pedantic, but a trade off with any new programming language is “having to learn a new language”. I haven’t programmed in zig but the syntax looks different enough from C that it would take a while to pick up.

xorvoid 4y ago

This 100% I’m darn sick of reading articles that don’t consider tradeoffs. Engineering can be defined as “a search for the optimal set of tradeoffs”. But, it seems like every article I ever read about new tech only discussed pros, not cons. I don’t get it. The cons are just as important, if not more so. Unfortunately, for some reason, people associate cons with flaws/weaknesses/failures rather than just a “point on the tradeoff curve”. Often: no perfect solution exists and those claiming otherwise are being dishonest. I would love to see this culture change at least for engineering literature where we should know better. All that said: I DO think that Zig has selected a reasonable point in the tradeoff curve. I just really want to understand that point better. How am I supposed to use it most effectively if I don’t understand it?

bsder 4y ago
Here is the question I think that you need to answer to choose between Rust and Zig: If your dependencies wrap more than 2 external libraries that have poor architecture, you're about to have a miserable time in Rust. Rust creates a lot of friction if an external library has a poor architecture. And, by default, most libraries have a very poor architecture. This leads to things like: "Giving up on wlroots-rs"--http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-in-c.html http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i... Talk about the issues of RLua--https://www.reddit.com/r/rust/comments/biq864/giving_up_on_wlrootsrs/ https://www.reddit.com/r/rust/comments/biq864/giving_up_on_w... "The thing that was SO tiring about writing this for me wasn't Rust, it was reasoning about the C library that I was binding. I'm just... tired of using C APIs! I'm tired of not having the compiler reason for me, I'm tired of having to second guess at what invariants the API expects and guess at what of a myriad of interesting non-local behavior a function call will do. I know that the Lua C API is a really, especially bad example, but I just don't know what the general solution is here." Consequently, this is where you get "Rewrite All The Things In Rust!" What's the point of fighting with Rust over all these nice safety guarantees and then throwing them out at the API boundary? If you can keep everything in Rust, this simply isn't an issue. This is where Zig shines. It catches some of the main classes of bugs but still lets you talk to libraries with crap architecture. Zig gets the fact that infrastructure and ecosystem matter--unlike everybody else operating in the C space (the cross compiling is phenomenal, for example, because they put a lot of work into it). Zig is doing some interesting things, but it's mostly some very solid choices with a lot of elbow grease applied. And that's worth a LOT. As an aside, I will also say that Zig feels better for embedded programming than Rust. Rust feels like it has stalled in embedded areas (things like sized integers, bitfield packing, placement construction of data structures, statics and globals that don't have locking overhead, lack of do-while, etc. although I would like to point out in Rust's favor that Rust finally got label-break-value which is a godsend when porting embedded code with goto error handling) while Zig has explicitly targeted those from the beginning. That makes Zig feel better for embedded from an ergonomic perspective, to my (obviously quite subjective) taste.

karmakaze 4y ago

I watched the video rather than read the short post. It did a good job getting into details that illustrate some of the tradeoffs. e.g. Do you want a small language that you can fully learn, or do you want a language with many features that you can spend time learning? Other things that are made explicit such as specifying an allocator on every allocation is an inconvenience that you pay for that flexibility. The choice of safety being added rather than assumed and later satisfied or declared an unsafe area is vastly different with a tradeoff in how developers use the language. An example given was how the self-hosted complier can use cache optimized untagged unions with the tags in a separate array. If I had to guess what the single biggest pattern of tradeoffs is, I'd say it's about being explicit rather than implicit. You gain fine-grained control at the cost of brevity/convenience.

naikrovek 4y ago

I don't trust any language comparison one-on-one with Rust, because fans of Rust today are just like fans of Python 20 years ago: "this language is the greatest accomplishment of humanity, easily," if I had to sum up the vibe I'm talking about. compare [language] with C, fairly and accurately, if you want me to believe a word you say.

kaba0 4y ago
There is not many languages that would fair worse next to C. For starters, not being able to create any form of even minimal, zero-cost abstractions like a vector is criminal.
- naikrovek 4y ago
  I think it's an apt comparison, Zig vs. C, given that Zig intends to replace C. Go was aiming to be a replacement for C as well, but they didn't even try to reach that goal because Go programs require an OS to run on; something must host the runtime, even though it's included in the binary. I love Go and I dislike C quite a bit. Zig vs. C seems fair to me, because there are no Zig zealots (or very few, at least not yet) and there are no C zealots who have lots of experience with C.
deleted 4y ago
[deleted]
Yoric 4y ago
That's funny, I read this affirmation (and variants thereof) rather often, but I've been using Rust on and off since 0.4 and I've always been discussing with developers who have balanced and careful opinions of Rust, starting with the Rust language and compiler teams. Rust has never been publicized as a solution to all problems. It happens to be my current favorite language for many tasks, but I don't think any serious Rust developer harbors the impression that Rust is designed to implement everything. That being said, the community is much larger these days, so I assume that there are users who do not have a sufficient PL background to understand the tradeoffs made in the design of Rust.

dingdingdang 4y ago

No standard utf8 string library is scary - I would happily learn all the mem gymnastics to make this work but fiddling with competing UTF8 libraries as is the case with C/C++ is just not my cuppa.

deleted 4y ago
[deleted]
anonymoushn 4y ago
There are functions for handling utf8 in the standard library.
- dingdingdang 4y ago
  Well, there's functions for working with code points within the bytes that (may) make up utf8 strings.. in order to do actual string level manipulation a library is needed (such as https://github.com/jecolon/ziglyph https://github.com/jecolon/ziglyph or others)