Hacker News Reader

Comment by scottlamb | Hacker News Reader

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

View on HN

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

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.

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.

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.

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?

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.

Are you a moderator?

Sorry for all the negativity. I added some clarifications, but it might have been a bit too late.

It's not just a matter of who is a moderator. It can be about the topic, what you are saying, or guideline issue. For clarification, you have to email HN.

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

And it could be used as drop in replacement for gcc/clang

https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

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.

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!

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.

Reply on news.ycombinator.com