4 ms·

How do you feel about zig?

• gavinhoward 3y ago
  I hate it.
  • throwawaymaths 3y ago
    Care to explain why?
    • gavinhoward 3y ago
      Several things, but I'll name two. comptime just doesn't fit my brain well. Async Zig gives me a headache. [1] [1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-colors/ https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...
      • throwawaymaths 3y ago
        Got it. Thank you for your perspective. I can appreciate that comptime is tricky. Indeed, async zig is hard and annoying (but you're wrong about the function coloring... Here is someone's project where they call an async function alternately from a sync or async context with zero lines of code: https://youtu.be/lDfjdGva3NE?t=1999 https://youtu.be/lDfjdGva3NE?t=1999 Yielding is async and threaded is sync)
        • gavinhoward 3y ago
          I'm not wrong. He claims that you can call functions fine in either mode if the functions are known at compile time. I never disputed that. If he tried to call those functions with possibly unknowable function pointers at runtime, I doubt it would work as well. There is a difference between compile time and runtime. At compile time, Zig can transform known functions to async to allow turn to call async functions. At runtime, that's not possible. The 75 examples in my post show that.
          • throwawaymaths 3y ago
            sure, a sync function and an async function get compiled to two different things under the hood, but IMO colored/uncolored is about ux, not what happens under the hood. In go, or erlang, which don't have async coloring, you don't actually care what the system does under the hood. More generically, if a system takes a private function and can choose to inline it, you probably wouldn't moan that under the hood it's doing something different and thus "inlining is function coloring". Maybe you would. I guess the question hinges on "just how hard" counts as "hard" for #3. I would say "not having to write an event loop because the compiler generates another version for the sync-calling-async with a single keyword" case counts as "not hard", but this is a matter of perspective. The language design still has rough edges, and you certainly ran into them, but with the function pointer stuff, I think you were really trying hard to break it to prove a specific point (this is a good thing! it will allow the team to fix it). To that point, they simply hadn't run into the specific runtime/comptime thing that you ran into, but it's pretty easy to see how exactly what you ran into can be addressed and fixed at comptime, it... just hasn't yet.
            • gavinhoward 3y ago
              It can't be addressed at compile time. That's the whole point of the uncomputability of the Halting Problem. The Zig compiler would have to have perfect knowledge of all functions that can be called anywhere. At compile time. Alan Turing proved that this is impossible. In other words, Zig cannot address it. Ever.
              • throwawaymaths 3y ago
                Ok? The universe of all code that can be created by the zig compiler is strictly bounded for any given project at any given time, the halting problem does not apply. At worst, you can do an exhaustive search. The context that you're running the code in can ultimately be known, and the pointer can be set to the appropriate version based on calling context.
                • gavinhoward 3y ago
• deleted 3y ago
  [deleted]