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

101–110 of 126 posts

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

#101

Post by pcwalton »

nicoburns wrote: post #90
pcwalton wrote: post #67

Earlier quoted context omitted.

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.

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.

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

#102

Post by [deleted] »

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…

[deleted]

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

#103

Post by mhh__ »

Quekid5 wrote: post #98
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!

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 from ones that use inline ASM that we have to be careful with).

With ImportC, D will be one of the better and non-hackier ways to interface C with other languages - i.e. introspection and metaprogramming but in a real language rather than some brain-dead DSL

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

#104

Post by WalterBright »

mhh__ wrote: post #103
Quekid5 wrote: post #98

Earlier quoted context omitted.

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!

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 - just compile the .c file with ImportC and D will access it just like any other module. D will even inline the C functions in it.

4. Use it as a standalone, small and fast, C compiler.

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

#105

Post by ifreund »

gigatexal wrote: post #80

Zig looks really compelling. Anyone use it in production?

This person has been for many months now: https://www.youtube.com/watch?v=124wdTckHNY

We hope to be using TigerBeetle which is written in zig in production in 2022: https://github.com/coilhq/tigerbeetle

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

#106

Post by pornel »

sm_ts wrote: post #51
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…

I've had to compile only a few times C/++ programs, and the experience can't be really compared to Rust (probably, to any other language :)). Lately I've cross-compiled a few times Linux/Windows programs, and the only thing I had to do (assuming that the underlying crates are compatible, and that the development libraries are in place, which is required for any language) was: rustup target add x86_64-pc-windows-gnu r…

That's true only for static libraries and pure-Rust projects. For executables and dynamic libraries Rust relies on system-provided linker (except nightly that can enable lld) and target libc already present on the OS (the nice part zig has, but Rust doesn't).

Rust totally craps out if you try to make a binary or dylib and you don't already have cross-compilation toolchain on your OS. It's doable from a Linux distro that has cross packages and a GNU target. It's a PITA for anything else, including anything from Windows and macOS hosts.

`zig cc` is actually useful even for cross-compiling Rust projects, because some Rust crates depend on C libraries.

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

#107

Post by wizzwizz4 »

chrsig wrote: post #78
wizzwizz4 wrote: post #73

Earlier quoted context omitted.

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

If you leak all the secrets 1% of the time, that's not leaking 1% of the secrets. All of the secrets have been leaked, albeit over a short stretch of time.

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

#108

Post by WalterBright »

Quekid5 wrote: post #98
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!

I admit it's been fun! My old C compiler (Datalight C) works well, but its coding practices are severely outdated. I wanted to see how it would look using modern practices.

P.S. I wouldn't be in the business if it wasn't fun.

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

#109

Post by csande17 »

msingle wrote: post #39
bionade24 wrote: post #34

Earlier quoted context omitted.

zig cc uses LLVM under the hood.

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!

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

#110

Post by pcwalton »

burntsushi wrote: post #97
pcwalton wrote: post #89

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

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