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

91–100 of 126 posts

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

#91

Post by coder543 »

pcwalton wrote: post #89
coder543 wrote: post #87

Earlier quoted context omitted.

Yes, the Zig (and Go) developers have clearly put a lot of effort into ensuring the size of their toolchain remains reasonable. I fully believe the Rust developers could achieve similar results as well, if they really wanted. Until then, the lack of a great cross compilation experience out of the box is just a limitation of the Rust toolchain. It's an acceptable limitation in many situations, but I don't buy your rep…

> Yes, the Zig (and Go) developers have clearly put a lot of effort into ensuring the size of their toolchain remains reasonable. I fully believe the Rust developers could achieve similar results as well, if they really wanted. I strongly disagree. These are different languages. Rust leans heavily on generics and monomorphization. It implements most language operations, like ptr::offset, in the language itself, incre…

> That's it. One more command than Zig or Go, to install the toolchain you need, and then you're off to the races.

Except it's not the same. Zig also cross-compiles C code beautifully, and lots of Rust code depends on C libraries. That "one additional command" does not solve cross compilation to an equivalent degree as Zig.

Go code tends to avoid C because of the heavy penalty that CGo imposes, so the cross compiliation experience is usually good there, but for different reasons than Zig.

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

#92

Post by coder543 »

kristoff_it wrote: post #85
coder543 wrote: post #75

Earlier quoted context omitted.

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

> it is apparently not obvious to the core Zig team I think it really is not obvious once you start thinking about all the implications. Right now the recommended way of reporting extra information alongside errors is by using a "diagnostics" struct. You can see an extremely effective example of that in zig-clap, for example. https://github.com/Hejsil/zig-clap Also this pattern was also mentioned in the issue you men…

To add one more comment... you should study the distribution of votes in that thread. Take a poll of the developers using Zig. Anywhere you look, I'm sure you will see that most people want error handling to include context by default.

84 upvotes for the initial issue is substantial in a community the size of Zig.

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

#93

Post by O_H_E »

vlovich123 wrote: post #54

Can it be used for c++ code? Also we build LLVM tip of tree from scratch. Is it easy to get the version of zig cc built against the newer version or does one have to wait for the project authors to update to the latest (I’m assuming my it’s a non-trivial amount of work?)

> Can it be used for c++ code?

Yup! https://github.com/ziglang/zig/commit/db17c0d88c44183b306099...

> Also we build LLVM tip of tree from scratch...

I would have also thought it would be non-trivial (Julia uses LLVM and has some non-backwards compatible patches) but this paragraph intrigued me:

>> At the time of this writing, LLVM 10 was just released two hours ago. It will take days or weeks for it to become available in various system package managers. But you can already download a master branch build of Zig and play with the new features of Clang/LLVM 10. For example, improved RISC-V support!

I found this for LLVM 12 (released April 14) https://github.com/ziglang/zig/commit/5a3ea9beced660c9cc463b... https://github.com/ziglang/zig/commit/e248de93a07fd6a7f48581... https://github.com/ziglang/zig/commit/6a7f21d1b8ca5c082c804e... https://github.com/ziglang/zig/commit/1438c324a460789f1004a3...

Andrew seem to be following along their release pretty closely.

Disclaimer: I don't know squat what I'm talking about

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

#94

Post by O_H_E »

interesting paragraph on why the builds are so small.

> You can download a 45 MiB tarball, unpack it, and you're done. You can even have multiple versions at the same time, no problem......Compare this to downloading Clang, which has 380 MiB Linux-distribution-specific tarballs. Zig's Linux tarballs are fully statically linked, and therefore work correctly on all Linux distributions. The size difference here comes because the Clang tarball ships with more utilities than a C compiler, as well as pre-compiled static libraries for both LLVM and Clang. Zig does not ship with any pre-compiled libraries; instead it ships with source code, and builds what it needs on-the-fly.

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

#95

Post by slimsag »

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…

I'd argue it's less about what the compiler does by default, but rather what it (and the community) enable.

For Mach (the Zig game engine I'm working on), I have a Zig build script which fetches the required parts of the macOS and iOS SDKs from GitHub to enable cross compilation from Windows/Linux -> macOS. Zig's linker, zld, enables that to work easily.[0]

For SDL.zig, they have also achieved cross compilation for most targets out of the box[1].

Contrast this to say, Go or Rust, where most GLFW and SDL bindings require mucking around with the system dependencies. It doesn't just work out of the box, I think that's really unfortunate and hope other languages work more towards painless installation of C-binding dependencies.

[0] https://twitter.com/slimsag/status/1413770578494775298

[1] https://github.com/MasterQ32/SDL.zig#support-matrix

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

#96

Post by kristoff_it »

coder543 wrote: post #88
kristoff_it wrote: post #85

Earlier quoted context omitted.

> it is apparently not obvious to the core Zig team I think it really is not obvious once you start thinking about all the implications. Right now the recommended way of reporting extra information alongside errors is by using a "diagnostics" struct. You can see an extremely effective example of that in zig-clap, for example. https://github.com/Hejsil/zig-clap Also this pattern was also mentioned in the issue you men…

> I think it really is not obvious once you start thinking about all the implications. No... it really is obvious. I've written quite a bit of C, C++, and Rust over the years, in addition to all sorts of garbage collected languages. I'm not writing this as an off-the-cuff thought. I've even written a similar comment before on HN about Zig's error handling. I've thought about this for a long time. It is just as obviou…

I'm still not convinced, but at the same time it's not up to me to decide. If you haven't done so already, I recommend you make your case in the relevant issue.

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

#97

Post by burntsushi »

pcwalton wrote: post #89
coder543 wrote: post #87

Earlier quoted context omitted.

Yes, the Zig (and Go) developers have clearly put a lot of effort into ensuring the size of their toolchain remains reasonable. I fully believe the Rust developers could achieve similar results as well, if they really wanted. Until then, the lack of a great cross compilation experience out of the box is just a limitation of the Rust toolchain. It's an acceptable limitation in many situations, but I don't buy your rep…

> Yes, the Zig (and Go) developers have clearly put a lot of effort into ensuring the size of their toolchain remains reasonable. I fully believe the Rust developers could achieve similar results as well, if they really wanted. I strongly disagree. These are different languages. Rust leans heavily on generics and monomorphization. It implements most language operations, like ptr::offset, in the language itself, incre…

The difference is really not just one command. I suggest you go out and actually try Zig cross compilation or at least read more about it. Andrew Kelley has written a lot about it. The work impressed me so much that it was one of the things that provoked me to become a financial supporter of Zig. (Even though I haven't written a line of Zig yet.)

Cross compilation in Rust is better than C or C++. But it's still a big pain.

I really think you are underestimating what the Zig folks are doing. Please investigate more deeply.

In particular: "Zig does not ship with any pre-compiled libraries; instead it ships with source code, and builds what it needs on-the-fly."

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

#98

Post by Quekid5 »

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…

This is getting super-weird, love it!

One assumes it is because C is so hard to rid ourselves of because POSIX (etc) that you're even entertaining this idea?

I mean, "it's fun" could also work as motivation, I guess.

I'm just curious!

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

#99

Post by steveklabnik »

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.

100% sure? No. Mind you, I'm on MSVC, where I already need an extra ~1gb download to get the system linker.

We could still do a few different things to make this story better for users, even if it's not literally identical.

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

#100

Post by steveklabnik »

pcwalton wrote: post #67
steveklabnik wrote: post #17

Earlier quoted context omitted.

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.

Sure, like many things, I bet you could pick three or four and get 90% of the default coverage. That still helps 90% of the users.

I also think you're really missing out on the "compile C code easily too" thing. That isn't very pleasant at all in Rust today.

(Finally, one reason it’s so big is that we ship binaries. This ships source. std-aware cargo could really help here.)

Post reply on HN