4 ms·

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

• 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.
      • kristoff_it 4y ago
        > I dunno if that's accurate? It's not, your understanding of async in Zig is sound. I would even add that in the blog post in question (my post, the one ghoward is replying to in his) I don't even dare to describe Zig as colorless, in fact I say colorblind.
        • ghoward 4y ago
          > It's not, your understanding of async in Zig is sound. Then perhaps there is something wrong with the language reference? > I don't even dare to describe Zig as colorless, in fact I say colorblind. Doesn't that mean my blog post is right? But my biggest beef is that people, including GP, used your blog post to then claim Zig is colorless. I mean, GP did it in GP.
          • kristoff_it 4y ago
            I don't really understand your crusade. I made this same observation in the past, it never satisfied you. Your blog post is full of wrong information. I tried to explain to you what was wrong when you first posted it (so you can refer to those comments, if you want), but you keep seeing this as some kind of philosophical debate, and I have no interest in having this debate. As I said to you already in the past, I just write software with Zig async and it works. Up to you what you want to do with your free time.
• 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