4 ms·

I'm not rooting for Zig [1] but I think there are some misses here, e.g.: > Cross-compilation looks like a standout feature in Zig, although C developers have

I'm not rooting for Zig [1] but I think there are some misses here, e.g.: > Cross-compilation looks like a standout feature in Zig, although C developers have been doing the same thing for decades. ... You can target an embedded ARM board or a RISC-V chip with one flag: Disagree: Zig's cross-compilation support is better than anything else. For one, installing a toolchain for a different OS/arch combo is not necessarily so easy with C. For another, with Zig you can target an arbitrary Linux glibc version with a commandline argument. Without Zig's toolchain, [2] the best I've seen is to run within a Docker container with that glibc version installed. [1] almost entirely because I think all new languages should have memory safety (via GC or borrow checking). [2] I see people linking Rust programs with Zig's toolchain for this reason: https://github.com/rust-cross/cargo-zigbuild https://github.com/rust-cross/cargo-zigbuild

tamnd 11mo ago
> [2] the best I've seen is to run within a Docker container with that glibc version installed. Agreed. I will revise that section tomorrow. Also, for compiling Go with CGO enabled, using Docker is the only reliable way to produce a binary correctly linked against glibc, especially when working with RHEL.
binary132 11mo ago
none of this needs to be batteries-included, and there is no reason it cannot be done just as straightforwardly for C-family languages as it has been for Zig and Rust.
- estebank 11mo ago
  This is true of almost everything: it's not that Zig or Rust are unique on most features. Most of them have existed in one shape or another before. The praise they receive is because of the level of polish their design and implementation have and how they interact with their other features. There's no one stopping other projects from doing the same thing (modulo technical and organisational considerations), but they haven't yet, so it is reasonable to highlight them. If people talk about how good X is in language Y enough, people from language Z might notice and "steal" it. That's a good thing!
  - binary132 11mo ago
    I’m saying these things aren’t “language features” at all. I applaud their creation, but “batteries built in” has always seemed to me like a terrible design decision compared to “batteries provided” especially considering that many of these things would have been perfectly satisfactory generic tooling. Now we have people yapping about C++ not having a build system because they’re all habituated to a world where every language has its own, different build system built in.
mtklein 11mo ago
Zig is so good at this, it is also probably the easiest way to cross-compile C.
- tamnd 11mo ago
  And it could be used as drop in replacement for gcc/clang https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
synergy20 11mo ago
generally speaking, cross compilation is a solved problem for common cpus on the market. on linux it's an installation step away, prepackaged and ready to use. for newer chips or some vendor-optimized-purpose etc, you have to rely on vendor's SDKs, zig can not help there either.
- alexrp 11mo ago
  The selling point is not merely cross-compilation; as pointed out in the other thread, it's the any-to-any cross-compilation for any supported target. With Zig, you get to download the compiler for any supported host target and then build binaries for Linux, macOS, Windows, FreeBSD, and NetBSD. In the near future, I intend to expand that list to include OpenBSD, illumos, and SerenityOS too.
  - rootnod3 11mo ago
    Yeah, but doesn't that also apply to GCC or LLVM? Download the target-system version and go compiling away. That is not unique to ZIG.
  - tamnd 11mo ago
    I really appreciate the enormous amount of work that has gone into Zig. Let me clarify my goal here: by writing this article I hope to hear solid counterpoints to the first one, which I didn't find very convincing, and to start a more constructive discussion. I'm also curious, how hard is it to a new target in Zig? For example, FreeBSD and NetBSD are already supported, but OpenBSD isn't yet. What are the main challenges blocking that?
    - abnercoimbre 11mo ago
      Dude your article got flagged, which means it's no longer on the feed. If you ever use LLMs for "technical accuracy" again, maybe actually test things on the command line.
      - tamnd 11mo ago
deleted 11mo ago
[deleted]

tamnd 11mo ago

> [2] the best I've seen is to run within a Docker container with that glibc version installed. Agreed. I will revise that section tomorrow. Also, for compiling Go with CGO enabled, using Docker is the only reliable way to produce a binary correctly linked against glibc, especially when working with RHEL.

binary132 11mo ago

none of this needs to be batteries-included, and there is no reason it cannot be done just as straightforwardly for C-family languages as it has been for Zig and Rust.

estebank 11mo ago
This is true of almost everything: it's not that Zig or Rust are unique on most features. Most of them have existed in one shape or another before. The praise they receive is because of the level of polish their design and implementation have and how they interact with their other features. There's no one stopping other projects from doing the same thing (modulo technical and organisational considerations), but they haven't yet, so it is reasonable to highlight them. If people talk about how good X is in language Y enough, people from language Z might notice and "steal" it. That's a good thing!
- binary132 11mo ago
  I’m saying these things aren’t “language features” at all. I applaud their creation, but “batteries built in” has always seemed to me like a terrible design decision compared to “batteries provided” especially considering that many of these things would have been perfectly satisfactory generic tooling. Now we have people yapping about C++ not having a build system because they’re all habituated to a world where every language has its own, different build system built in.

mtklein 11mo ago

Zig is so good at this, it is also probably the easiest way to cross-compile C.

tamnd 11mo ago
And it could be used as drop in replacement for gcc/clang https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

synergy20 11mo ago

generally speaking, cross compilation is a solved problem for common cpus on the market. on linux it's an installation step away, prepackaged and ready to use. for newer chips or some vendor-optimized-purpose etc, you have to rely on vendor's SDKs, zig can not help there either.

alexrp 11mo ago
The selling point is not merely cross-compilation; as pointed out in the other thread, it's the any-to-any cross-compilation for any supported target. With Zig, you get to download the compiler for any supported host target and then build binaries for Linux, macOS, Windows, FreeBSD, and NetBSD. In the near future, I intend to expand that list to include OpenBSD, illumos, and SerenityOS too.
- rootnod3 11mo ago
  Yeah, but doesn't that also apply to GCC or LLVM? Download the target-system version and go compiling away. That is not unique to ZIG.
- tamnd 11mo ago
  I really appreciate the enormous amount of work that has gone into Zig. Let me clarify my goal here: by writing this article I hope to hear solid counterpoints to the first one, which I didn't find very convincing, and to start a more constructive discussion. I'm also curious, how hard is it to a new target in Zig? For example, FreeBSD and NetBSD are already supported, but OpenBSD isn't yet. What are the main challenges blocking that?
  - abnercoimbre 11mo ago
    Dude your article got flagged, which means it's no longer on the feed. If you ever use LLMs for "technical accuracy" again, maybe actually test things on the command line.
    - tamnd 11mo ago

deleted 11mo ago

[deleted]