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

31–40 of 126 posts

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

#31

Post by geodel »

ksec wrote: post #22

From Release Note 0.8 Roadmap [1], >The major theme of the 0.9.0 release cycle will be stabilizing the language, creating a first draft of the language specification, and self-hosting the compiler. So I am guessing we could see 1.0 release within 12 months time? Or will there be 0.10 or 0.11 after that? I am just eager to hear people's comments and opinions for using it in production within their context and edge cas…

I guess at least 2 major things after 0.9 would be package manager, library standardization and cleanup which would take many releases and perhaps need to be done before 1.0

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

#32

Post by tialaramex »

DrBazza wrote: post #15
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…

It's always a bit harsh comparing a 36 year old language with more-or-less full backwards compatibility, with a new language designed with the benefit of hindsight. That's not to say that it's impossible to do something like that in a C++ compiler but it's going to be more work than there is benefit. Tangentially related: https://twitter.com/__phantomderp/status/1416108650809241601 C++ also tries to bring in modern p…

The octopus analogy seems especially appropriate. The thing about the legs on an actual octopus is that there's a bunch of local compute substrate in them, if you were to nail extra legs onto the octopus those are rubbish compared to its real legs which can think.

For example, move semantics are a peg leg for the octopus. Should an octopus have a peg leg? I'm not a biologist of any sort, but my guess is "No". I can see why C++ wanted to add move (without this performance in some scenarios is just awful) and yet since C++ didn't start out having move semantics and can't give up backward compatibility it has to shoehorn them in with this awkward "hollowed out object" idea. The result is performance still isn't where it could be and the feature is unergonomic.

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

#35

Post by tialaramex »

rhn_mk1 wrote: post #23
_benj wrote: post #14

I’ve been learning Zig for a few months now and what I’m in love with is the ability to just use Zig to interact with whatever C libraries I want, but doing so with the conveniences that Zig offers. I want to use SDL2 and cairo and pango? No problem! GTK4, easy peasy! There’s a C lib that comes as a single .c file that makes it easier to interact with SDL? Drop it on the project folder and compile it with Zig along a…

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 since I read it). If you are too lazy to do it by hand, or find the technique works but wish it less manual, this is what Leakdice does:

https://github.com/tialaramex/leakdice OR https://github.com/tialaramex/leakdice-rust

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

#36

Post by klyrs »

_benj wrote: post #14

I’ve been learning Zig for a few months now and what I’m in love with is the ability to just use Zig to interact with whatever C libraries I want, but doing so with the conveniences that Zig offers. I want to use SDL2 and cairo and pango? No problem! GTK4, easy peasy! There’s a C lib that comes as a single .c file that makes it easier to interact with SDL? Drop it on the project folder and compile it with Zig along a…

Omg, skip the rest but valgrind is amazing and requires almost zero learning to use. Build your code with debug symbols, find inputs that trigger a segfault, then run it under valgrind. It then reports out of bounds memory access, with a full stacktrace. It's got a billion more uses, but at the most basic, that one use-case will keep you from wasting time futzing with a debugger or print-debugging 99% of segfaults and memory leaks.

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

#37

Post by jcalvinowens »

klyrs wrote: post #36
_benj wrote: post #14

I’ve been learning Zig for a few months now and what I’m in love with is the ability to just use Zig to interact with whatever C libraries I want, but doing so with the conveniences that Zig offers. I want to use SDL2 and cairo and pango? No problem! GTK4, easy peasy! There’s a C lib that comes as a single .c file that makes it easier to interact with SDL? Drop it on the project folder and compile it with Zig along a…

Omg, skip the rest but valgrind is amazing and requires almost zero learning to use. Build your code with debug symbols, find inputs that trigger a segfault, then run it under valgrind. It then reports out of bounds memory access, with a full stacktrace. It's got a billion more uses, but at the most basic, that one use-case will keep you from wasting time futzing with a debugger or print-debugging 99% of segfaults an…

Have you tried ASAN? If you like valgrind, you will be in love with ASAN, it's really surpassed it at this point IMHO.

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

#38

Post by zamadatix »

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.

I'm not sure what's really "missed", if you call a library other than the stdlib of course you're going to need to provide the appropriate headers/libraries for that as that's got nothing to do with a C compiler.

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

#39

Post by msingle »

bionade24 wrote: post #34
lou1306 wrote: post #10

It does look impressive! Does anyone know if Zig exposes some APIs to extract/manipulate/analyze the AST of the C program? It might be a nice alternative to LLVM, which I find a little overwhelming.

zig cc uses LLVM under the hood.

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

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

#40

Post by vvanders »

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.

Yup, fully agreed Zig stands above others here. Cross compiling C/C++ is just a special kind of hell. Each target always has some sort of bespoke toolchain and build environment constraint that add so much unneeded complexity.
Post reply on HN