5 ms·

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 source

by 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.

by davemp 1y ago

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.