Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig cc: A drop-in replacement for GCC/Clang (2020)

andrewkelley.me

Post reply on HN
Print view View original

61–70 of 126 posts

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#61

Post by azakai »

wyldfire wrote: post #7
gus_massa wrote: post #2

I don't understand the difference. Is "zig cc" more smart to find included files than the other compilers?

zig distributes critical stuff like C library headers and libs. So it's not smarter, just more convenient. Built in support for several OS/architecture combos.

In addition, zig cc uses a remarkable compile+cache mechanism, which makes it possible to distribute a single build that can be used to cross-compile anything. It will cross-compile the necessary files as you need them, transparently - without downloading a new toolchain for each target, and quickly.

zig cc is really, really cool, and it's incredibly generous that it provides zig's benefits to users of C and C++ as well.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#62

Post by chrsig »

skeetmtp wrote: post #52
jedisct1 wrote: post #47

Earlier quoted context omitted.

Be careful with ASAN on cryptographic code, though. It can introduce side channels.

ASAN is not meant to be used in production though. Or I missed something in your comment.

I've seen it advised to periodically release to production with ASAN/UBSAN/TSAN enabled, with the intention that it's only 1/nth of a deployment, and even then, only deployed for enough time to collect instrumentation. I don't have a citation to share, so take with as many grains of salt as you feel appropriate.

If nothing else, I appreciate the advisement that it can have security implications.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#63

Post by kevin_thibedeau »

flohofwoe wrote: post #60
pjmlp wrote: post #8

Earlier quoted context omitted.

What this kind of stories always miss is that the host platform needs all system libraries for the target platform for anything beyond the basic examples using the standard library. E.g. try to cross compile Metal shading example for iOS from Linux with zig, or do a Win2D UWP rendering application from Linux with zig.

The Metal shader compiler is an unfortunate special case, because the bytecode and the Metal compiler tools are proprietary and locked up by Apple (there are precompiled binaries of the Metal compiler for Windows, but not Linux). The ball is definitely in Apple's court here, there's nothing any language project can do, except illegally reverse engineering Metal bytecode, which obviously isn't a good idea. The system…

> illegally reverse engineering Metal bytecode

Reverse engineering is legal in the US (unless bound by contract).

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#64

Post by pcwalton »

steveklabnik wrote: post #58
sobeston wrote: post #57

Earlier quoted context omitted.

I think Zig does cross compilation (ignoring for the moment, projects with C dependencies) better because it comes out-of-the-box with the libraries and headers needed to target a lot of systems. In Rust, you typically get additional toolchains via rustup, whereas Zig works on all of the targets with a single install.

Absolutely, hence a toolchain thing.

Are you sure that we should be shipping all targets by default into one monster download? This doesn't seem particularly scalable.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#65

Post by pcwalton »

pjmlp wrote: post #8
pornel wrote: post #6

I really like what they've done for cross-compilation. Automatically selecting appropriate libc/crt implementation is such a relief. Compared to Zig, cross-compilation in C/C++/Rust seems downright user-hostile: you have to obtain the correct cross-sdk, but it won't tell you which one, or how to get it (some combos don't even exist), or even where to put it. If you don't guess everything correctly, it will fail with…

What this kind of stories always miss is that the host platform needs all system libraries for the target platform for anything beyond the basic examples using the standard library. E.g. try to cross compile Metal shading example for iOS from Linux with zig, or do a Win2D UWP rendering application from Linux with zig.

Right. Are you going to ship all Windows headers and import libraries to everyone, including DirectX, etc.? Are you going to keep them up to date with every new version of a Windows component? Are you going to ship parts of the macOS, or iOS SDKs?

I don't see shipping all targets all the time to be a particularly scalable solution in general. When you start including all libraries necessary to develop actual apps, the download size will eventually get so big that people will complain. Just make it easy for developers to get the targets they need, but don't ship everything by default.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#66

Post by pcwalton »

flohofwoe wrote: post #60
pjmlp wrote: post #8

Earlier quoted context omitted.

What this kind of stories always miss is that the host platform needs all system libraries for the target platform for anything beyond the basic examples using the standard library. E.g. try to cross compile Metal shading example for iOS from Linux with zig, or do a Win2D UWP rendering application from Linux with zig.

The Metal shader compiler is an unfortunate special case, because the bytecode and the Metal compiler tools are proprietary and locked up by Apple (there are precompiled binaries of the Metal compiler for Windows, but not Linux). The ball is definitely in Apple's court here, there's nothing any language project can do, except illegally reverse engineering Metal bytecode, which obviously isn't a good idea. The system…

So does every new release of any Windows component require a new version of Zig? That doesn't seem sustainable.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#67

Post by pcwalton »

steveklabnik wrote: post #17
vvanders wrote: post #12

Earlier quoted context omitted.

I would not include Rust in that list, in my experience rustup and cargo are miles ahead of C/C++ when cross compiling.

Personally, I see it in three tiers: Rust improved upon those experiences, but I still wish someone would implement what Zig has in rustc.

I don't. We could approximate it by shipping all targets by default, but few really want that and the few who do can just install those targets with rustup.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#68

Post by p0nce »

pcwalton wrote: post #65
pjmlp wrote: post #8

Earlier quoted context omitted.

What this kind of stories always miss is that the host platform needs all system libraries for the target platform for anything beyond the basic examples using the standard library. E.g. try to cross compile Metal shading example for iOS from Linux with zig, or do a Win2D UWP rendering application from Linux with zig.

Right. Are you going to ship all Windows headers and import libraries to everyone, including DirectX, etc.? Are you going to keep them up to date with every new version of a Windows component? Are you going to ship parts of the macOS, or iOS SDKs? I don't see shipping all targets all the time to be a particularly scalable solution in general. When you start including all libraries necessary to develop actual apps, th…

> Just make it easy for developers to get the targets they need, but don't ship everything by default.

It seems to be what Flutter is doing, and it must be a ton of work.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#69

Post by jlarocco »

wyldfire wrote: post #7
gus_massa wrote: post #2

I don't understand the difference. Is "zig cc" more smart to find included files than the other compilers?

zig distributes critical stuff like C library headers and libs. So it's not smarter, just more convenient. Built in support for several OS/architecture combos.

When you put it that way, this is an unfair comparison and the downsides are more obvious.

With GCC and Clang, I only pay for cross compilation if I need it, so for a fair comparison, the cross-compiler libraries should be installed for GCC and Clang. Also with GCC and Clang, I don't have to worry about a third party (the Zig team) incorporating bug and security fixes from upstream. And with GCC I get support for more platforms.

If I have chosen to use cross-compilation, building for alternative architectures is just as easy as for Zig.

Re: Zig cc: A drop-in replacement for GCC/Clang (2020)

#70

Post by coder543 »

pcwalton wrote: post #64
steveklabnik wrote: post #58

Earlier quoted context omitted.

Absolutely, hence a toolchain thing.

Are you sure that we should be shipping all targets by default into one monster download? This doesn't seem particularly scalable.

The whole toolchain for Zig, which appears to include complete cross compilation, is less than 40MB compressed[0]. I would hardly call that a "monster download".

I think developers can spare that much space. Besides, storage space is scaling much faster than the number of available targets, so I don't see how this could be "not particularly scalable" unless you either have a weird definition of "target" or predict there's going to be a sudden explosion in the number of targets.

Go also makes cross compilation to any supported target a breeze in the default toolchain download, and it is an incredible convenience for the developer.

[0]: https://ziglang.org/download/

Post reply on HN