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

71–80 of 126 posts

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

#71

Post by pjmlp »

jedisct1 wrote: post #50
pjmlp wrote: post #29

Earlier quoted context omitted.

Actually you can do the same with clang. Emscripten just installs a bunch of stuff to make it easier to use existing libraries. If you just want to use standard library, no need for extra stuff. https://surma.dev/things/c-to-webassembly/

Only for freestanding webassembly. In order to target WASI, you have to install the builtins ( https://github.com/jedisct1/libclang_rt.builtins-wasm32.a ), as well as the WASI libc, and fiddle with `—-sysroot`. Zig can target both without having to install anything else.

Assuming that you even need them.

Zig packages them, naturally you don't need to install them a second time.

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

#72

Post by msoucy »

WalterBright wrote: post #49

D is taking a different approach. D is getting a builtin C compiler (called ImportC) that is a from scratch C compiler, now in prototype form. https://dlang.org/spec/importc.html It works by having an extra module called cparse.d https://github.com/dlang/dmd/blob/master/src/dmd/cparse.d which parses Standard C. The lexer and semantic routines of the D compiler are then tweaked to support C semantics. The same optimiz…

I miss playing with D. It looks like you've done a lot of neat stuff recently, but I just don't have a project that I can use it for. I remember being thoroughly impressed with its metaprogramming capabilities in college when I was working on dproto.

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

#73

Post by wizzwizz4 »

chrsig wrote: post #62
skeetmtp wrote: post #52

Earlier quoted context omitted.

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.

> with the intention that it's only 1/nth of a deployment, and even then, only deployed for enough time to collect instrumentation

You can't unleak secrets.

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

#74

Post by unilynx »

tialaramex wrote: post #35
rhn_mk1 wrote: post #23

Earlier quoted context omitted.

Note that none of autotools, make, and valgrind are required for C. You could be building with meson and ninja. Valgrind is also more useful than just for C, although admittedly it's most useful for binaries that have parts written in unchecked languages like C.

Right. Even in an entirely safe language you can have leaks, and valgrind is an effective way to find those leaks if you can afford the virtualisation overhead. If you can't afford the virtualisation overhead, and you need to find leaks you should try what Raymond Chen suggests in "The poor man's way of identifying memory leaks" (not bothering to link since Microsoft will only move it anyway, they have several times…

http://bytepointer.com/resources/old_new_thing/20050815_224_...

(a site that tries to keep a proper backup of the ever moving writings of Chen)

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

#75

Post by coder543 »

manish_gill wrote: post #53

I literally started learning Zig today after watching a talk on youtube by Andrew Kelly. The drop-in C compiler replacement lured me. But what surprised me immediately and the thing I'm absolutely loving is the error handling ( https://twitter.com/mgill25/status/1416720958988210177 ) and the comptime features. I've done Rust and while I love what it's doing, getting into low-level C-world without the overhead of a la…

The thing I dislike about Zig error handling is that there's no way to associate informational context with an error. Bubbling the errors up, you'll eventually print out a string to the console that says "error: AccessDenied". The sysadmin/user running your software will be left baffled. Access denied... to what?!

Zig is 90% of the way there with error handling, but it is extremely obvious to me that you need to be able to have error context carried with the error... it is apparently not obvious to the core Zig team[0], and this is a major impediment to my interest.

Sure, if you're compiling to a microcontroller, maybe you're willing to sacrifice usability to avoid error values ever allocating... but most developers can spare an allocation for errors, especially given that error handling is generally not the hot path.

[0]: https://github.com/ziglang/zig/issues/2647 (among other issues)

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

#76

Post by pcwalton »

coder543 wrote: post #70
pcwalton wrote: post #64

Earlier quoted context omitted.

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 th…

The Xcode download, which is the only officially-supported way to develop native apps on macOS and iOS, is 9.8 GB and gets larger with every update. The Windows 10 SDK is 4 GB and likewise is only getting larger. Sure, you can develop some apps with only a subset of the SDK. But, as a language project, do you really want to be in the business of optimizing and subsetting every single OS SDK?

I think a lot of the issue here comes down to targeting server workloads and command-line tools vs. apps using more of the OS libraries. In practice, Go focuses on the former kinds of apps, so shipping all targets is a more viable approach for them. But when you start getting into apps that want to use a larger swath of the platform facilities, then the size of the platform SDKs starts to become an issue.

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

#77

Post by flohofwoe »

pcwalton wrote: post #66
flohofwoe wrote: post #60

Earlier quoted context omitted.

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.

I don't actually know what Windows components mingw supports in detail and how often mingw is updated because of that, but I guess that the important Win32 APIs are stable. I suppose that the new APIs which are highly in flux could be supported by separate packages, like this: https://github.com/marlersoft/zigwin32)

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

#78

Post by chrsig »

wizzwizz4 wrote: post #73
chrsig wrote: post #62

Earlier quoted context omitted.

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.

> with the intention that it's only 1/nth of a deployment, and even then, only deployed for enough time to collect instrumentation You can't unleak secrets.

I agree with you, but I don't understand intent of your comment.

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

#79

Post by coder543 »

pcwalton wrote: post #76
coder543 wrote: post #70

Earlier quoted context omitted.

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 th…

The Xcode download, which is the only officially-supported way to develop native apps on macOS and iOS, is 9.8 GB and gets larger with every update. The Windows 10 SDK is 4 GB and likewise is only getting larger. Sure, you can develop some apps with only a subset of the SDK. But, as a language project, do you really want to be in the business of optimizing and subsetting every single OS SDK? I think a lot of the issu…

No one (that I've seen) is suggesting to include those SDKs, which you probably don't even have the rights to redistribute anyways.

I provided both Zig and Go as examples of what people are looking for, and their downloads are neither obscenely large nor do they include those massive SDKs.

So yes, you have a weird definition of "target" that no one else here is using, and it is disingenuous for the conversation. rustup can already add additional targets after installation, are you suggesting this downloads 10GB SDKs? Definitely not, and that sounds irrelevant. (Even once you do this, the toolchain experience is not as good as what Zig or Go offer.)

Compare what Zig and Go do to what Rust does, not some strawman argument that would require users to download 10GB of SDK with the Rust toolchain. Alternatively, find me someone who is saying they think these multi-gigabyte SDKs should be included, because I don't see that anywhere in this conversation.

People here are complimenting what Zig currently does, which takes less than 40MB compressed. Zig can cross compile to Windows just fine. There are limitations to everything, but what Zig and Go offer is strictly better than what Rust offers in terms of the out-of-box cross compilation experience, and it isn't unduly burdensome on the developers like your proposed 10GB download.

Post reply on HN