5 ms·

I wonder if Zig is getting too much hype at the moment considering its immaturity (and so many easy to hit bugs as noted by other commenters). Is it getting hyp

I wonder if Zig is getting too much hype at the moment considering its immaturity (and so many easy to hit bugs as noted by other commenters). Is it getting hype before it's ready? Will it be able to recover from that?

ksec 4y ago
Compared to Rust at this stage of its development? No, Rust was far more popular. If you search headline with Zig which reached HN front page, you will only see about 1 - 2 per month. Compared that to Rust, which isn't even as popular as it once was. But still, I do wish the Zig community could quiet down a little bit. It would be nice if decent zig submission hit HN front page once every two months. Keeping the interest alive but not too much so people felt it is over hyped. We will have a November Release soon and I can guarantee it will hit HN front page again.
ghoward 4y ago
Disclaimer: Not a Zig fan. I think Zig is getting too much hype. It's unfortunate because Zig could have potential, but hyping something before it's ready is a recipe for alienating early adopters and killing progress towards popularity. The worst part of it is that I've heard people say that they've got Zig in production; with all of the bugs in the compiler, they are apt to get burned, and too many burns will lead to putting out the fire and rewriting. It doesn't help that (in my opinion) there is confusion regarding basic things about Zig. [1] [1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-colors/ https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...
- nyberg 4y ago
  A number of those using zig in production have played with zig for a considerable amount of time (I started playing with 0.5.0 where large breaking changes came shortly after) thus know what to expect. Afaik most of those are within embedded, using it as a toolchain (zig cc not zig), or have similar constraints.
- kbd 4y ago
  Ugh that "Zig has function coloring" post again. The misunderstanding that post makes is that function coloring refers to at compile time. In other words, in Zig you don't need to write two versions of a function to use it in async vs sync context. Obviously the functions will have different runtime representations, so if you do something that cares about runtime calling conventions or w/e then yes you do need to worry about how the function is used, which is unavoidable.
  - gavinhoward 4y ago
    The person you are replying to (me) is the author of that post. > The misunderstanding that post makes is that function coloring refers to at compile time. The original function colors post referred to runtime, so you're wrong. > In other words, in Zig you don't need to write two versions of a function to use it in async vs sync context. This is correct, if you only care about compile time. > Obviously the functions will have different runtime representations, so if you do something that cares about runtime calling conventions or w/e then yes you do need to worry about how the function is used, which is unavoidable. So you admit that Zig does have function colors? Also, according to the actual Zig documentation, which I quote in my post, there is only one version of every function; if a function is used in an async context, even if it is sync otherwise, the compiler makes the function async and continues on its merry way, so there is only one runtime representation of a function. Here's the quote from the documentation: > Zig infers that a function is async when it observes that the function contains a suspension point. Async functions can be called the same as normal functions. A function call of an async function is a suspend point. Saying that Zig does not have function colors because it hides them at compile time is a little disingenuous, in my opinion. It still has them, but like a statically-typed language with type inference, it just hides that fact, but only at compile time.
    - kbd 4y ago
      > Saying that Zig does not have function colors because it hides them at compile time is a little disingenuous, in my opinion. Not to impugn your character, but I feel the same way about the points you're making. > So you admit that Zig does have function colors? Not in any meaningful way, no. Again, the runtime representation of async vs sync functions is unavoidably different, and has nothing to do with the language. The fact that Zig lets you write one function definition that can be called in sync vs async contexts (unless you're specifically choosing to do sync vs async things) is what it means to be colorless! > Also, according to the actual Zig documentation, which I quote in my post, there is only one version of every function; if a function is used in an async context, even if it is sync otherwise, the compiler makes the function async and continues on its merry way, so there is only one runtime representation of a function. I dunno if that's accurate? Someone with more knowledge of Zig internals would have to confirm, but I assume if the same codebase uses a function in each context it'll be monomorphized into the specific version needed, same as generics. I don't think that's contradicted by what you quoted.
- int_19h 4y ago
  How would you expect a language as low-level as Zig is to support colorless async? It pretty much requires some kind of green threads.
  - pjmlp 4y ago
    Maybe like Modula-2?
  - ghoward 4y ago
    I agree, and that's okay, but the problem is that many people assume Zig is colorless. I just want to dispel that notion.
    - throwawaymaths 4y ago
      Only by your definition. Colorless was always about DX, nowhere in the original article did anyone care about implementation. And this stuff does matter. I have created libraries which provides calls in both sync and async contexts to the same function and it works just fine.
      - ghoward 4y ago
        Does developer experience not include using function pointers in Zig?
        anonymoushn 4y ago
        How is calling non-async functions via @asyncCall insufficient?
        ghoward 4y ago
        @asyncCall is exactly the sort of thing the original function colors calls out.
        4y ago
kristoff_it 4y ago
> Is it getting hype before it's ready? Will it be able to recover from that? Isn't that the very definition of hype? :^) We can't hide in a cave to build everything in secret until it's ready because otherwise we wouldn't have the money to pay contributors, or we would be forced to get funding through other means (I mention that point in the blog post). And while we do want to be in the open, you can see that in my writing I never talk about a future that's distant and completely unproven. Even the most forward-looking stuff I mention, like incremental compilation, has at least had a proof of concept to show that it's not pure fiction. I'm obviously biased, but I think we're in a pretty good spot when it comes to gathering public interest vs getting things done.
- thefaux 4y ago
  > We can't hide in a cave to build everything in secret until it's ready because otherwise we wouldn't have the money to pay contributors, or we would be forced to get funding through other means (I mention that point in the blog post). Can you see though how this model can cause a lack of trust in external observers? Your development model is reliant on attracting attention to drive funding. There are some major incentive problems here. I want to be clear that I am not suggesting that you are deliberately doing this but your model actually incentivizes building a lower quality product. You just need to make something appealing enough that people start using it and then, once they are invested in the language, some of them may be willing to pay you to fix the issues they find or build new features that would be useful to them. If the language didn't have issues, there would be no reason to pay you to fix them. I know I will likely get downvoted for this but I believe in what I say.
  - Tozen 4y ago
    > Can you see though how this model can cause a lack of trust in external observers? Your development model is reliant on attracting attention to drive funding. There are some major incentive problems here... You just need to make something appealing enough that people start using it and then, once they are invested in the language, some of them may be willing to pay you to fix the issues they find or build new features that would be useful to them. As also a 3rd party observer, there is an obvious partial counter to the argument that you made. In the case of free and open-source, people are investing money or time because they believe in the product and its potential usefulness. That the product will deliver, for all people invested and for all users, is clearly unrealistic. There is no such thing as a "sure thing". It's more a matter of if the product delivers for enough people. And if anything, if unsatisfied, people are free to jump to the next candidate or savior that floats by. I think the more valid aspect of the point presented, is the lack of trust or suspicions coming from when the hype is paid for and doesn't come from the grassroots and actual users. To include, negative propaganda campaigns targeting competing languages. > If the language didn't have issues, there would be no reason to pay you to fix them. All languages will have issues. I've always found this curious about people having such expectations. Maybe the argument is more valid in terms of the total amount of issues and bugs, but then that would need to be a fair and relative comparison to other languages. There is no such thing as a bug-free perfect language. While other parts of your post were "more valid" or at least points worth considering, I think on this point, it kind of fell off the mark. > I know I will likely get downvoted for this but I believe in what I say. Odd, that's exactly what happened. The tribalism is arguably too severe, which may relate to the money involved, that the downvoting is so predictable.

ksec 4y ago

Compared to Rust at this stage of its development? No, Rust was far more popular. If you search headline with Zig which reached HN front page, you will only see about 1 - 2 per month. Compared that to Rust, which isn't even as popular as it once was. But still, I do wish the Zig community could quiet down a little bit. It would be nice if decent zig submission hit HN front page once every two months. Keeping the interest alive but not too much so people felt it is over hyped. We will have a November Release soon and I can guarantee it will hit HN front page again.

ghoward 4y ago

Disclaimer: Not a Zig fan. I think Zig is getting too much hype. It's unfortunate because Zig could have potential, but hyping something before it's ready is a recipe for alienating early adopters and killing progress towards popularity. The worst part of it is that I've heard people say that they've got Zig in production; with all of the bugs in the compiler, they are apt to get burned, and too many burns will lead to putting out the fire and rewriting. It doesn't help that (in my opinion) there is confusion regarding basic things about Zig. [1] [1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-colors/ https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...

nyberg 4y ago
A number of those using zig in production have played with zig for a considerable amount of time (I started playing with 0.5.0 where large breaking changes came shortly after) thus know what to expect. Afaik most of those are within embedded, using it as a toolchain (zig cc not zig), or have similar constraints.
kbd 4y ago
Ugh that "Zig has function coloring" post again. The misunderstanding that post makes is that function coloring refers to at compile time. In other words, in Zig you don't need to write two versions of a function to use it in async vs sync context. Obviously the functions will have different runtime representations, so if you do something that cares about runtime calling conventions or w/e then yes you do need to worry about how the function is used, which is unavoidable.
- gavinhoward 4y ago
  The person you are replying to (me) is the author of that post. > The misunderstanding that post makes is that function coloring refers to at compile time. The original function colors post referred to runtime, so you're wrong. > In other words, in Zig you don't need to write two versions of a function to use it in async vs sync context. This is correct, if you only care about compile time. > Obviously the functions will have different runtime representations, so if you do something that cares about runtime calling conventions or w/e then yes you do need to worry about how the function is used, which is unavoidable. So you admit that Zig does have function colors? Also, according to the actual Zig documentation, which I quote in my post, there is only one version of every function; if a function is used in an async context, even if it is sync otherwise, the compiler makes the function async and continues on its merry way, so there is only one runtime representation of a function. Here's the quote from the documentation: > Zig infers that a function is async when it observes that the function contains a suspension point. Async functions can be called the same as normal functions. A function call of an async function is a suspend point. Saying that Zig does not have function colors because it hides them at compile time is a little disingenuous, in my opinion. It still has them, but like a statically-typed language with type inference, it just hides that fact, but only at compile time.
  - kbd 4y ago
    > Saying that Zig does not have function colors because it hides them at compile time is a little disingenuous, in my opinion. Not to impugn your character, but I feel the same way about the points you're making. > So you admit that Zig does have function colors? Not in any meaningful way, no. Again, the runtime representation of async vs sync functions is unavoidably different, and has nothing to do with the language. The fact that Zig lets you write one function definition that can be called in sync vs async contexts (unless you're specifically choosing to do sync vs async things) is what it means to be colorless! > Also, according to the actual Zig documentation, which I quote in my post, there is only one version of every function; if a function is used in an async context, even if it is sync otherwise, the compiler makes the function async and continues on its merry way, so there is only one runtime representation of a function. I dunno if that's accurate? Someone with more knowledge of Zig internals would have to confirm, but I assume if the same codebase uses a function in each context it'll be monomorphized into the specific version needed, same as generics. I don't think that's contradicted by what you quoted.
int_19h 4y ago
How would you expect a language as low-level as Zig is to support colorless async? It pretty much requires some kind of green threads.
- pjmlp 4y ago
  Maybe like Modula-2?
- ghoward 4y ago
  I agree, and that's okay, but the problem is that many people assume Zig is colorless. I just want to dispel that notion.
  - throwawaymaths 4y ago
    Only by your definition. Colorless was always about DX, nowhere in the original article did anyone care about implementation. And this stuff does matter. I have created libraries which provides calls in both sync and async contexts to the same function and it works just fine.
    - ghoward 4y ago
      Does developer experience not include using function pointers in Zig?
      - anonymoushn 4y ago
        How is calling non-async functions via @asyncCall insufficient?
        ghoward 4y ago
        @asyncCall is exactly the sort of thing the original function colors calls out.
        4y ago

kristoff_it 4y ago

> Is it getting hype before it's ready? Will it be able to recover from that? Isn't that the very definition of hype? :^) We can't hide in a cave to build everything in secret until it's ready because otherwise we wouldn't have the money to pay contributors, or we would be forced to get funding through other means (I mention that point in the blog post). And while we do want to be in the open, you can see that in my writing I never talk about a future that's distant and completely unproven. Even the most forward-looking stuff I mention, like incremental compilation, has at least had a proof of concept to show that it's not pure fiction. I'm obviously biased, but I think we're in a pretty good spot when it comes to gathering public interest vs getting things done.

thefaux 4y ago
> We can't hide in a cave to build everything in secret until it's ready because otherwise we wouldn't have the money to pay contributors, or we would be forced to get funding through other means (I mention that point in the blog post). Can you see though how this model can cause a lack of trust in external observers? Your development model is reliant on attracting attention to drive funding. There are some major incentive problems here. I want to be clear that I am not suggesting that you are deliberately doing this but your model actually incentivizes building a lower quality product. You just need to make something appealing enough that people start using it and then, once they are invested in the language, some of them may be willing to pay you to fix the issues they find or build new features that would be useful to them. If the language didn't have issues, there would be no reason to pay you to fix them. I know I will likely get downvoted for this but I believe in what I say.
- Tozen 4y ago
  > Can you see though how this model can cause a lack of trust in external observers? Your development model is reliant on attracting attention to drive funding. There are some major incentive problems here... You just need to make something appealing enough that people start using it and then, once they are invested in the language, some of them may be willing to pay you to fix the issues they find or build new features that would be useful to them. As also a 3rd party observer, there is an obvious partial counter to the argument that you made. In the case of free and open-source, people are investing money or time because they believe in the product and its potential usefulness. That the product will deliver, for all people invested and for all users, is clearly unrealistic. There is no such thing as a "sure thing". It's more a matter of if the product delivers for enough people. And if anything, if unsatisfied, people are free to jump to the next candidate or savior that floats by. I think the more valid aspect of the point presented, is the lack of trust or suspicions coming from when the hype is paid for and doesn't come from the grassroots and actual users. To include, negative propaganda campaigns targeting competing languages. > If the language didn't have issues, there would be no reason to pay you to fix them. All languages will have issues. I've always found this curious about people having such expectations. Maybe the argument is more valid in terms of the total amount of issues and bugs, but then that would need to be a fair and relative comparison to other languages. There is no such thing as a bug-free perfect language. While other parts of your post were "more valid" or at least points worth considering, I think on this point, it kind of fell off the mark. > I know I will likely get downvoted for this but I believe in what I say. Odd, that's exactly what happened. The tribalism is arguably too severe, which may relate to the money involved, that the downvoting is so predictable.