5 ms·

I hate it.

by gavinhoward 4y ago

I hate it.

throwawaymaths 4y ago
Care to explain why?
- gavinhoward 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y ago
        No, you can't do an exhaustive search. Say you're a library author. You distribute pre-built library files. You've already lost because the compiler does not know your clients' code when it compiles your library. I am not kidding when I say it's provably impossible.
        throwawaymaths 4y ago
        "pre-built library files" are not a thing in zig right now, unless you use the c abi, which doesn't have async? Even supposing zig had prebuilding someday, you would probably have to extern it using async directly declared in the callconv (.async is an option in callconv) and so yes, the compiler would know. It's just that currently zig has a lot of "let the compiler figure out". Maybe that's what's making you uncomfortable? I'm pretty sure the zig compiler is finite and deterministic, so sophistry around the halting problem doesn't apply.
        gavinhoward 4y ago
        Wat. The Zig compiler is finite and deterministic, yes, but that's not the problem. The problem is that user code is not finite nor deterministic. Even worse, Zig's compiler may be deterministic and finite, but the language is not, by far. In fact, the language is one of the most infinite languages in existence because just the type system is uncomputable! [1] (In this context, the word "undecidable" used by that source means "uncomputable".) If the type system is uncomputable, then the type system will never be able to resolve all uses of function pointers everywhere. The whole point of the Halting Problem is that you could have a finite and deterministic Turing Machine that runs other Turing Machines, and that finite and deterministic Turing Machine could run into situation where it never halts. I never say this when people ask (because most people don't understand), but the real reason I don't like Zig is because of how infinite the language is, starting with its uncomputable type system. This makes Zig one of the most unreasonable [2] programming languages in existence. If you don't believe me, ask the Zig team how they plan to solve this problem. Don't ask them if they plan to solve it; ask them how. Then if they reply, email me [3] with their proposed solution, and I will destroy it. I will do that no matter how many solutions they come up with because math says I will always win. But if they say they can't, will you believe them? [1]: https://3fx.ch/typing-is-hard.html#zig https://3fx.ch/typing-is-hard.html#zig [2]: https://fsharpforfunandprofit.com/posts/is-your-language-unreasonable/ https://fsharpforfunandprofit.com/posts/is-your-language-unr... [3]: https://gavinhoward.com/contact/ https://gavinhoward.com/contact/

I hate it.

throwawaymaths 4y ago

Care to explain why?

gavinhoward 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y ago
        No, you can't do an exhaustive search. Say you're a library author. You distribute pre-built library files. You've already lost because the compiler does not know your clients' code when it compiles your library. I am not kidding when I say it's provably impossible.
        throwawaymaths 4y ago
        "pre-built library files" are not a thing in zig right now, unless you use the c abi, which doesn't have async? Even supposing zig had prebuilding someday, you would probably have to extern it using async directly declared in the callconv (.async is an option in callconv) and so yes, the compiler would know. It's just that currently zig has a lot of "let the compiler figure out". Maybe that's what's making you uncomfortable? I'm pretty sure the zig compiler is finite and deterministic, so sophistry around the halting problem doesn't apply.
        gavinhoward 4y ago
        Wat. The Zig compiler is finite and deterministic, yes, but that's not the problem. The problem is that user code is not finite nor deterministic. Even worse, Zig's compiler may be deterministic and finite, but the language is not, by far. In fact, the language is one of the most infinite languages in existence because just the type system is uncomputable! [1] (In this context, the word "undecidable" used by that source means "uncomputable".) If the type system is uncomputable, then the type system will never be able to resolve all uses of function pointers everywhere. The whole point of the Halting Problem is that you could have a finite and deterministic Turing Machine that runs other Turing Machines, and that finite and deterministic Turing Machine could run into situation where it never halts. I never say this when people ask (because most people don't understand), but the real reason I don't like Zig is because of how infinite the language is, starting with its uncomputable type system. This makes Zig one of the most unreasonable [2] programming languages in existence. If you don't believe me, ask the Zig team how they plan to solve this problem. Don't ask them if they plan to solve it; ask them how. Then if they reply, email me [3] with their proposed solution, and I will destroy it. I will do that no matter how many solutions they come up with because math says I will always win. But if they say they can't, will you believe them? [1]: https://3fx.ch/typing-is-hard.html#zig https://3fx.ch/typing-is-hard.html#zig [2]: https://fsharpforfunandprofit.com/posts/is-your-language-unreasonable/ https://fsharpforfunandprofit.com/posts/is-your-language-unr... [3]: https://gavinhoward.com/contact/ https://gavinhoward.com/contact/