6 ms·

I'm the former kind: I choose C because I like it above all else. [1] That said, like the author, I'm trying to find an alternative. Well, more like I'm buildi

I'm the former kind: I choose C because I like it above all else. [1] That said, like the author, I'm trying to find an alternative. Well, more like I'm building my alternative because I hate Go. And Rust. And anything else. I don't know why C fits my brain, but it does. I think it's because my brain is low-level; I like messing with assembler when I get the chance to optimize. [1]: https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-in-memory-safety/ https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...

tacitusarc 4y ago
How do you feel about zig?
- 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.
- deleted 4y ago
  [deleted]
preseinger 4y ago
it's not possible for human beings to write correct C code, measured over time this is not a controversial statement, it's the clear conclusion from any evaluation of available evidence it's fine that you like messing with assembler, but you can't do that safely -- if the programs you write don't need to be correct then carry on, but if they do need to be correct, then you have a professional obligation to use a higher-level language, with stronger guarantees edit: > This brings me to my next reason: I have the discipline to write C at a high level. factually, you do not. nobody does. you think you do, until you don't. human cognition is insufficient to satisfy this requirement. "discipline" does not fix the problem.
- jtorsella 4y ago
  Oh wow, someone should alert the Linux kernel maintainers. Do you want to tell them that it’s impossible to write correct C code? And the rust compiler team, too. After all, if nobody can write safe assembly then whatever they’re doing is either unsafe or magically gets the computer to understand rust directly. Or are they relying on LLVM for their code generation? I forget what language that’s written in, but nothing “unsafe” happens there surely. All code is machine code at bottom. Including the code that maintains abstractions convincing enough for you to think the “memory-safety” of rust or any other language is a static and guaranteed thing and not something that needs “unsafe” scaffolding to support it.
  - preseinger 4y ago
    i'm sure the linux kernel maintainers already know that it's impossible for them to write correct C code, no need to tell them
  - tialaramex 4y ago
    The Rust compiler developers are well aware that it's not possible to write 100% correct code at scale, not least for their dependencies, LLVM provides Rust with ICE (cases where your program crashes the compiler) and with soundness holes where the LLVM behaviour is definitely wrong but it's arguably exactly why and so until LLVM developers decide why it's wrong and fix it, Rust has to either work around that or accept sub-par results. Much of the Rust compiler is written in Rust and so has fewer problems.
pier25 4y ago
What type of projects do you work on?
- gavinhoward 4y ago
  A compiler/interpreter, build system, init system, version control system, among others. It's all in a monorepo that has my "libc".
GoblinSlayer 4y ago
>I have special array types that I use instead of straight pointers, and those arrays store their bounds. You cheat. You don't write C the hard way. But ok, that's an easier way to use C today.
- gavinhoward 4y ago
  Okay? I mean, I have the discipline to admit I need to do that and the discipline to actually do it. I'm okay with cheating if it reduces bugs.

tacitusarc 4y ago

How do you feel about zig?

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.
deleted 4y ago
[deleted]

preseinger 4y ago

it's not possible for human beings to write correct C code, measured over time this is not a controversial statement, it's the clear conclusion from any evaluation of available evidence it's fine that you like messing with assembler, but you can't do that safely -- if the programs you write don't need to be correct then carry on, but if they do need to be correct, then you have a professional obligation to use a higher-level language, with stronger guarantees edit: > This brings me to my next reason: I have the discipline to write C at a high level. factually, you do not. nobody does. you think you do, until you don't. human cognition is insufficient to satisfy this requirement. "discipline" does not fix the problem.

jtorsella 4y ago
Oh wow, someone should alert the Linux kernel maintainers. Do you want to tell them that it’s impossible to write correct C code? And the rust compiler team, too. After all, if nobody can write safe assembly then whatever they’re doing is either unsafe or magically gets the computer to understand rust directly. Or are they relying on LLVM for their code generation? I forget what language that’s written in, but nothing “unsafe” happens there surely. All code is machine code at bottom. Including the code that maintains abstractions convincing enough for you to think the “memory-safety” of rust or any other language is a static and guaranteed thing and not something that needs “unsafe” scaffolding to support it.
- preseinger 4y ago
  i'm sure the linux kernel maintainers already know that it's impossible for them to write correct C code, no need to tell them
- tialaramex 4y ago
  The Rust compiler developers are well aware that it's not possible to write 100% correct code at scale, not least for their dependencies, LLVM provides Rust with ICE (cases where your program crashes the compiler) and with soundness holes where the LLVM behaviour is definitely wrong but it's arguably exactly why and so until LLVM developers decide why it's wrong and fix it, Rust has to either work around that or accept sub-par results. Much of the Rust compiler is written in Rust and so has fewer problems.

pier25 4y ago

What type of projects do you work on?

gavinhoward 4y ago
A compiler/interpreter, build system, init system, version control system, among others. It's all in a monorepo that has my "libc".

GoblinSlayer 4y ago

>I have special array types that I use instead of straight pointers, and those arrays store their bounds. You cheat. You don't write C the hard way. But ok, that's an easier way to use C today.

gavinhoward 4y ago
Okay? I mean, I have the discipline to admit I need to do that and the discipline to actually do it. I'm okay with cheating if it reduces bugs.