Live data from Hacker News

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

andrewkelley.me

111–120 of 126 posts

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

#111

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

It's obvious that error context is vitally needed. What's not obvious is how to accomplish this in the language without compromising other things such as simplicity. Pick any solution, and a new set of problems rear their ugly heads. That's not to say it can't be solved. The proposal is open; neither rejected nor accepted.

For especially difficult language design decisions, I like to work on other language changes that I am more confident about as a way to anchor the design, and then revisit the difficult questions, hopefully armed with more guidance from the rest of the language design being in place.

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

#112
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…

The metal compiler probably could run with darling

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

#113
post #39

Earlier quoted context omitted.

right now - my understanding is once the self-hosted compiler is done, LLVM will be optional.

I believe the plan is to make LLVM optional for compiling Zig code, but features that work with C code will still require Clang to be compiled in. Who knows, though. Someone might end up implementing a C compiler on top of the self-hosted Zig compiler's backend!

From what I understand, LLVM will still be used for release builds, while the self-holsted compiler will be used for quick feedback.

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

#114
post #7

Earlier quoted context omitted.

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.

Although as mentioned in the article, this won't work on systems like *BSD, Solaris or macOS.

One tiny correction that we do support seamless C/C++ cross-compilation to macOS now with the advent of our own in-house linker `zig ld`. :-)

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

#115
post #103

Earlier quoted context omitted.

A decent subset of D programmers have used C and have been majorly bitten by it before, so it's definitely not a marriage of love put it that way. ImportC is, in my view, about optics and a little convenience - using C with D is already trivial if you understand how C works, ImportC just makes it offensively easy to do. There are some less theoretical things too, i.e. no more keeping kernel headers up to date (apart…

The reasons for ImportC are: 1. It's no longer necessary to translate .h files to D to interface with C. While doing the translations isn't hard, it is tedious, and if there are a lot of .h files it becomes a barrier. 2. .h files get updated over time, and correspondingly updating the D files is error prone. It's much more effective to just compile the new .h files. 3. It is not necessary to even create a .h file - j…

I'm glad D is finally delivering on its promise. I remember looking at it years ago disappointed that "you can use C from D!" meant writing and maintaining wrapper libraries for every damn thing.

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

#116

Earlier quoted context omitted.

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…

Do you think that Rust would be a better language if everything had to be compiled from source?

If you use the build-std nightly feature you can compile the entire standard library, even for a custom JSON target file, and it goes pretty quick. With a bit of attention that feature would be just fine at filling in the gaps in rustup’s prebuilt targets.

But Zig’s approach isn’t actually about making everyone compile more things from scratch. It doesn’t compile libc from scratch any time you select a new target. Reading the article you can see the extreme lengths it goes to to avoid this.

The main thing that’s missing from Rust is target-specific libc.so/etc, and an appropriate linker for every target. If you try cross compiling anything, you will soon run into this problem; your system will not have the correct target libc or an appropriate linker. You can generally only change one part of the triple before the experience starts falling apart. I can cross compile for iOS/tvOS/etc on my Mac; that’s about it.

Zig manages to solve this for all its targets by pre-processing simplifications of the various libcs, which are then bundled into the Zig binary (as 3 very small files). It generates a useless but linkable .so file from the preprocessed files for any target on the fly. It gets you the correct libc headers. Then it uses LLD instead of making you hunt around on Ubuntu forum posts finding and downloading the correct GNU linker for your specific architecture. So you don’t link to a real libc, but you don’t have to compile one either. (Until you want to execute a binary with QEMU, but usually non-simulated target machines have a libc.so already.)

(Aside: Golang solves this by not depending on libc at all, by reimplementing most of it including the syscalls in Go, and I believe by using its own multi-target linker. Many pros and many cons, but an approach Google is happy to sponsor.)

If you’re saying this approach would be infeasible for Rust std/core, then yes obviously. It’s statically linked, you can’t get away with a fake .so file.

But that was never really the issue. Rustc can build std’s rlib files for any target effortlessly. And yet cross compiling is still a pretty poor experience. The state of the art for Rust developers at the moment is rust-embedded/cross, which solves the same libc+linker problem that Zig does, naively, by literally using Docker and per-target Ubuntu images to download prebuilt GCC and libc packages from Apt. Basically we can do way better than that, because Zig showed us how.

See this Dockerfile for what I mean: https://github.com/rust-embedded/cross/blob/master/docker/Do...

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

#117

Earlier quoted context omitted.

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…

Do you think that Rust would be a better language if everything had to be compiled from source?

Obviously I don't. And that's totally consistent with learning from Zig about how to improve the cross compilation story for Rust. (Trivially: compile some things from source, but not other things.)

I'm honestly pretty disappointed at your participation in this thread. It seems like you're going out of your way to assume the worst possible interpretation of what folks are saying.

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

#118

Earlier quoted context omitted.

Is it really few who want that? Anybody developing server software on windows or mac and deploying on linux could use this. Anybody developing cross-platform client software could use it. I'd guess that a lot of Rust developers currently do development on their target platform, but that's because cross compiling is such a pain. If it were as easy as zig or go then things might well be differen.

My x86_64 Rust libraries directory is 86MB. `rustup target list | wc -l` spits out 84 for me. The math doesn't add up.

Is rust cross-compilation really is straightforward as just installing the target triple and then it "just works" (including linking and C FFI compilation)?

My understanding was that most people were using "cross" docker images for "cross-compilation", because setting up native actual cross-compilation was quite involved.

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

#119

Earlier quoted context omitted.

$ alias zcc='zig cc' Only works interactively, though.

shopt -s expand_aliases Put that at the top of your bash scripts and aliases will work there too.

Nice!! I've been programming shells for ~30 years and I learn this only today :-(

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

#120

Earlier quoted context omitted.

My x86_64 Rust libraries directory is 86MB. `rustup target list | wc -l` spits out 84 for me. The math doesn't add up.

Is rust cross-compilation really is straightforward as just installing the target triple and then it "just works" (including linking and C FFI compilation)? My understanding was that most people were using "cross" docker images for "cross-compilation", because setting up native actual cross-compilation was quite involved.

No, it isn't that easy. pcwalton is misrepresenting things here IMO.

Yes, people, including myself, use 'cross' precisely because it isn't as easy as "just use rustup to install the desired target." 'cross' has a bunch of Docker images that set up the cross compilation toolchains, and those images represent a fair amount of domain knowledge that I don't have to tediously acquire to use it.

Post reply on HN