3 ms·

Back when it still had async support, I looked at using Zig in QEMU. My main qualm with it is that it doesn't try to integrate with existing C programs. The id

Back when it still had async support, I looked at using Zig in QEMU. My main qualm with it is that it doesn't try to integrate with existing C programs. The ideal C replacement for me would be a two-way per-file C transpiler, in the same way as the Vala language was. Cython also works the same way even though it's not a C replacement. Having to know the full set of Zig sources in advance due to error types, and the strong accent on Zig as a build system, are both a non starter for integration in existing large C programs, for example.

anonymoushn 1y ago
You can't have monomorphization or the old async feature if you need to be able to convert individual files to C.
- bonzini 1y ago
  You can do it in multiple passes (analysis/dumping IR followed by code generation, with dep files to connect them). It's what Rust does internally with rmeta files. Mine is not necessarily a criticism of Zig, mind. It's a criticism of what is needed from a C replacement.
davemp 1y ago
Replacing C != coexisting seamlessly. Exposing an idiomatic C interface by default would handcuff Zig’s own design. > Having to know the full set of Zig sources in advance due to error types You can just catch all of the errors and translate them back into errno or whatever homegrown scheme your c project is using. - - - Does the zig compiler not support generating .o’s without a build.zig? I like the zig build system so much that I’ve migrated some large projects that will likely never contain a line of zig, so I haven’t felt that pain point.
- kristoff_it 1y ago
  > Does the zig compiler not support generating .o’s without a build.zig? Of course it does, all the build system does is orchestrate invocations to the other basic zig subcommands (`build-exe`, `build-lib`, `build-obj`, etc). You can invoke `zig build-obj` and get an object file in whatever flavor you prefer.
  - davemp 1y ago
    So you can just extern the functions you want, handle all the errors internally, and stick it into your makefile with? %.o: %.zig zig build-obj *.zig -o *.o Not sure I get OP’s complaint then.
    - bonzini 1y ago
      Anything that produces object files is a lot harder to debug and maintain than a transpiler.
      - davemp 1y ago
        Not sure I agree. If you’re going zig->C->obj, you’d still have to fix the zig source if you find an issue in the C level. If you don’t want to learn or debug in a new language then you should probably just stick with C? The goal of zig as far as I know is to make it so you can transition away from C completely. Maintaining a C target seems antithetical to breaking ties with the “C machine”.
        bonzini 1y ago
        Yes, as I said I am looking at it exclusively from the point of view of replacing C for new code in existing programs, with a smaller cost than for example adding safe Rust bindings.

anonymoushn 1y ago

You can't have monomorphization or the old async feature if you need to be able to convert individual files to C.

bonzini 1y ago
You can do it in multiple passes (analysis/dumping IR followed by code generation, with dep files to connect them). It's what Rust does internally with rmeta files. Mine is not necessarily a criticism of Zig, mind. It's a criticism of what is needed from a C replacement.

davemp 1y ago

Replacing C != coexisting seamlessly. Exposing an idiomatic C interface by default would handcuff Zig’s own design. > Having to know the full set of Zig sources in advance due to error types You can just catch all of the errors and translate them back into errno or whatever homegrown scheme your c project is using. - - - Does the zig compiler not support generating .o’s without a build.zig? I like the zig build system so much that I’ve migrated some large projects that will likely never contain a line of zig, so I haven’t felt that pain point.

kristoff_it 1y ago
> Does the zig compiler not support generating .o’s without a build.zig? Of course it does, all the build system does is orchestrate invocations to the other basic zig subcommands (`build-exe`, `build-lib`, `build-obj`, etc). You can invoke `zig build-obj` and get an object file in whatever flavor you prefer.
- davemp 1y ago
  So you can just extern the functions you want, handle all the errors internally, and stick it into your makefile with? %.o: %.zig zig build-obj *.zig -o *.o Not sure I get OP’s complaint then.
  - bonzini 1y ago
    Anything that produces object files is a lot harder to debug and maintain than a transpiler.
    - davemp 1y ago
      Not sure I agree. If you’re going zig->C->obj, you’d still have to fix the zig source if you find an issue in the C level. If you don’t want to learn or debug in a new language then you should probably just stick with C? The goal of zig as far as I know is to make it so you can transition away from C completely. Maintaining a C target seems antithetical to breaking ties with the “C machine”.
      - bonzini 1y ago
        Yes, as I said I am looking at it exclusively from the point of view of replacing C for new code in existing programs, with a smaller cost than for example adding safe Rust bindings.