
Zig cc: A drop-in replacement for GCC/Clang - hazebooth
https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html
======
Shoop
Really incredible work and it's been very fun to follow along. The streams
where Andrew did the last part of this work can be seen here: [1], [2].

I am really happy that someone is making the effort to steadily simplify
systems programming rather than make it more complicated. Linux goes to such
incredible lengths to be bug-for-bug backwards compatible, but then the
complexities of all of our layers of libcs, shared libraries, libsystemd,
dbus, etc cause unnecessary pain and breakage at every level. Furthermore,
cross-compiling C code across different architectures on Linux is far harder
than it needs to be. I have a feeling that there wouldn't be as much interest
in the steady stream of sandboxes and virtual machines (JVM, NaCl, PNaCl,
flatpak, docker, WebAssembly) if we could just simplify the layers and layers
of cruft and abstractions in compiler toolchains, libc implementations, and
shared libraries. Practically every laptop and server processor use the exact
same amd64 architecture, but we have squandered this opportunity by adding
leaky abstractions at so many levels. I can't wait until installing a program
on linux is as simple as downloading a static executable and just running it
and I hope zig brings this future.

[1]
[https://www.youtube.com/watch?v=2u2lEJv7Ukw](https://www.youtube.com/watch?v=2u2lEJv7Ukw)
[2]
[https://www.youtube.com/watch?v=5S2YArCx6vU](https://www.youtube.com/watch?v=5S2YArCx6vU)

~~~
Wowfunhappy
Linux and GCC today have the ability to compile and run fully static
executables, I don't understand why this isn't done...

~~~
jcelerier
N°1 most harmful post on the internet :
[https://akkadia.org/drepper/no_static_linking.html](https://akkadia.org/drepper/no_static_linking.html)

I am convinced that Drepper's insistence on dynamic linking has set the linux
desktop useability and developer friendliness back literal decades.

~~~
umvi
I work on an embedded linux system that has 256 MB of RAM. That can get eaten
up really fast if every process has its own copy of everything.

~~~
userbinator
~15 years ago my "daily driver" had 256MB of RAM and it was perfectly usable
for development (native, none of this new bloated web stuff) as well as lots
of multitasking. There was rarely a time when I ran out of RAM or had the CPU
at full usage for extended periods.

Now it seems even the most trivial of apps needs more than that just to start
running, and on a workstation, less than a year old with 4 cores of i7 and
32GB of RAM, I still experience lots of lag and swapping (fast SSD helps,
althougn not much) doing simple things like reading an email.

~~~
smabie
Are you sure? I've been running Linux for a long time with no page file. From
4gb to 32gb (The amount of RAM I have now) and have literally only ran out of
RAM once (and that was because of a bug in a ML program I was developing). I
find it very hard to believe that you experience any swapping at all with
32gb, much less "lots".

~~~
userbinator
You've likely not experienced the amazing monstrosity that is Microsoft Teams:

[https://answers.microsoft.com/en-
us/msoffice/forum/all/teams...](https://answers.microsoft.com/en-
us/msoffice/forum/all/teams-hogging-memory-running-
slowly/3a5ddd1a-e4b0-41be-881d-c0d46b9abe23)

There's a screenshot in there showing it taking 22GB of RAM. I've personally
never seen it go that high, but the 10-12GB of RAM that I have seen is
absolutely ludicrous for a _chat app_. Even when it's initially started it
takes over 600MB. Combine that with a few VMs that also need a few GB of RAM
each, as well as another equally-bloated Electron app or two, and you can
quickly get into the swapping zone.

~~~
syockit
I also experience the same thing with Mattermost (the client also being an
Electron app). The memory bloat usually comes from switching back and forth
from so many channels, scrolling up to load more chat history, and lots and
lots of image attachments (and of course, the emoticons).

~~~
userbinator
_scrolling up to load more chat history, and lots and lots of image
attachments (and of course, the emoticons)._

I remember comfortably browsing webpages with lots of large images and
animated GIFs in the early 2000s, with a fraction of the computing power I
have today. Something has become seriously inefficient with browser-based
apps.

------
airstrike
> Take a moment to appreciate what just happened here - I downloaded a Windows
> build of Zig, ran it in Wine, using it to cross compile for Linux, and then
> ran the binary natively. Computers are fun!

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

Hot damn! You had me at Hello, World!

~~~
crazypython
Dlang is a better C. DMD, the reference compiler for Dlang, can also compile
and link with C programs. It can even compile and link with C++03 programs.

It has manual memory management as well as garbage collection. You could call
it hybrid memory management. You can manually delete GC objects, as well as
allocate GC objects into manually allocated memory.

The Zig website says "The reference implementation uses LLVM as a backend for
state of the art optimizations." However, LLVM is consistently 5% worse than
the GCC toolchain at performance across multiple benchmarks. In contrast, GCC
9 and 10 officially support Dlang.

Help us update the GCC D compiler frontend to the latest DMD.

Help us merge the direct-interface-to-C++ into LLVM D Compiler main.
[https://github.com/Syniurge/Calypso](https://github.com/Syniurge/Calypso)

Help us port the standard library to WASM.

~~~
kick
D seems like its pitch is "a better C++," but "a better C" doesn't seem quite
right.

~~~
nurettin
D's whole premise of "being a better C++" has always made them look like
argumentative jerks. Why build a language on top of a controversy? Their main
argument from early 2000s: C++ requires a stdlib and compiler toolchain is not
required to provide one. Wtf D? I mean I understand that C++ provides a lot of
abstractions on top of C to call itself "more" than C, but what does D provide
other than a few conveniences? If you even consider garbage collection or
better looking syntax or more consistent, less orthogonal sytax a convenience.
It didn't even have most of it's current features when it was first out back
in early 2000s. Trying to gain adoption through creating some sort of
counterculture what are they? 14?. /oneparagraphrant

~~~
diegoperini
It is probably the case that D has a brilliant engineer team who doesn't
really focus on the PR side of things. D definitely provides value over C/C++
other than a few sugars for the syntax. It is just not communicated that well.

------
hardwaregeek
I'd love for a hotlist or even prize for programmers doing awesome stuff like
this. Off the top of my head, Andrew, Andreas Kling of Serenity OS, whoever
ffwff is ([https://github.com/ffwff/](https://github.com/ffwff/)), Niko
Matsakis of Rust, and so on. It'd be very awesome to have a roundtable with
some of these people. They could discuss different approaches to design, their
own histories and plans for the future. I loved reading Coders at Work, but I
felt that there was a missed opportunity by not having the subjects interact
with each other. So many of them had similar and very dissimilar
ideas/approaches, which would have made for a wonderful discussion.

If someone could do the same but for a younger generation, I think it'd be
very valuable.

------
emmanueloga_
The cross compiling features of Zig look fantastic! Installation is so easy,
just downloading and extracting a single file.

Should every compiler stack have prioritized cross compilation over other
features? (I vote: YES). Cross compiling programs has always been a PITA for
most languages.

It would be great if Zig cc could be paired with vcpkg [1] for a nice cross-
compiling development environment. Looks like vckpg requires a C++ compiler
though.

1: [https://github.com/microsoft/vcpkg](https://github.com/microsoft/vcpkg)

~~~
Hello71
Which reasonably-popular modern languages can be reasonably said to have
ignored cross compilation? Interpreted languages like JavaScript and Python
obviously don't have any problem, JIT languages like .NET and Java explicitly
have a cross-platform layer, and modern compiled languages like Go and Rust
specifically have cross-compilation as a goal. Rust still needs a libc though,
but that's not Rust's fault, that's the result of trying to work together with
the system instead of DIYing everything. (see: problems with Go doing system
calls on BSDs, Solaris, etc)

You can't look at C which started in the 1970s and C++ which started in the
1980s and have expected them to even consider cross-compilation, when Autoconf
wasn't even released until 1991.

~~~
emmanueloga_
I think the benchmark should be distribution. For instance, you mention
"JavaScript and Python obviously don't have any problem", but say you want to
create a distributable program for the 3 major operating systems, based in one
of those languages, and you can't assume the user will have an installed
interpreter. I don't think you will find any _standard_ solutions.

Most other languages make it _possible_ to generate some sort of artifact
usable from different operating systems but not necessarily easy. I think Java
only relatively recently included a standard way to create a bundle including
a minimal JVM distribution with an app to make it usable when the user doesn't
have an installed JVM (and again, there were a bunch of different non standard
solutions of varying quality before that). Even now I wouldn't say the Java
solution is easy to use.

I could continue in this fashion with different languages, but you get the
idea.

I heard go is pretty good in ease of cross compilation, and well, looks like
Zig is doing great in this area too. Ah! .net core is apparently pretty good
in this area these days too.

~~~
Hello71
That's moving the bar though. Only in the past decade or so has it become
reasonable ("reasonable") to include entire runtimes together with an
application. Java started in 1995, Python started in 1991. This was an era
when one of Java's main targets was SIM cards and other highly minimal
devices, so not only would the target already have a JVM, but it would be
wholly impractical to ship your own. Even on desktops, downloading just a
fraction of Java for each program would be a massive waste of limited
bandwidth and disk space.

For that reason, Java and Python didn't start out with fully self-contained
bundles as a design goal. It just wasn't practical in the 90s. Obviously, yes,
if they had managed to correctly predict and plan for three decades of
technological improvement, then sure, we'd be working in a very different
technological landscape. But they couldn't possibly have, and solutions built
on the old languages are always fraught with disagreement. So, we use new
languages, like Go and Rust, which are developed with modern needs in mind.

------
drfuchs
Zig (the language) is very appealing as a "better C than C". Check out
[https://ziglang.org](https://ziglang.org) (dis-disclaimer: I'm unaffiliated.)

~~~
ifreund
Aye, and it lives up to that claim as well in my opinion, despite being still
relatively young and pre-1.0. My favorite thing about Zig is that it has
managed to stay simple and solve many of the problems of C without resorting
to greatly increased complexity like Rust (which is much more of a C++
replacement than a C replacement in my opinion).

~~~
LessDmesg
Rust is not a C++ replacement, nor a C replacement. It targets its own niche
(embedded, realtime, correctness-oriented). It's a totally different
development culture. Zig, OTOH, is absolutely a C replacement.

~~~
bregma
My day job is maintaining the toolchains for a popular safety-certified
realtime embedded operating system. I have never once been asked to provide a
Rust toolchain. Fortran, yes. Ada, yes. Python and Go, yes. By and large it's
just C (and more and more C++).

Rust seems to be mostly something "full stack developers" and "back end
developers" embrace for server-side toys and hobby projects.

~~~
nicoburns
Python, on a realtime embedded operating system? Rust isn't really there for
embedded development yet. It's great for low-level code on full-blown
processors/OSs though

~~~
bregma
Python: customers ask, I deliver.

Top-end embedded processors have GPUs and hypervisors these days and run AI
algorithms to, say, detect lane changes and do parallel-parking maneuvers.
These days AI means code written in Python and Fortran.

------
AndyKelley
Thanks everyone for the kind words! It's been a lot of work to get this far,
and the Zig project has further to go still.

If you have a few bucks per month to spare, consider chipping in. I'm hoping
to have enough funds soon to hire a second full time developer.

[https://github.com/users/andrewrk/sponsorship](https://github.com/users/andrewrk/sponsorship)

~~~
BubRoss
Why does zig purposely fail on windows text files by default? Do you really
expect a language to catch on when you are purposely alienating windows users
by refusing to parse \r for some bizarre reason?

~~~
losvedir
And here I was just amazed from the blog post at the Windows support in cross
compilation in either direction.

I find it hard to believe that someone could be capable of writing a non-
trivial program but not able to change their text editor settings to use \n.

~~~
BubRoss
Every compiler handles it fine, I just can't wrap my head around why someone
would intentionally cripple their software to alienate the vast majority of
their potential users. I understand the problem and how to solve it, but it's
such a giant red flag there is no way I'll care about this language. Most
people probably don't actually understand why it fails and why a simple hello
world program fails.

I'm floored that so many people would ignore this barrier to entry and somehow
rationalize such a ridiculous design choice. If you make things straight up
break for all windows users by default in your new language, it's going
nowhere. No rationalization or excuses will change that reality.

~~~
akavel
Among programmers, distinction between CRLF and LF is known. Among non-
programmers, you may well see people who will try to write code in WordPad,
and that doesn't mean compilera should parse WordPad documents as source
files. Do you expect people to write code in Notepad? If not, any reasonable
programmer's editor supports Unix EOLs. Guide them to use Notepad++ or VSCode
with proper options/plugins, case closed. Otherwise, you may as well complain
about handling of mixed tabs & spaces in Python, or the fact that C requires
semicolons.

~~~
BubRoss
Defaults cause zig to error out. This isn't that hard to understand or fix. It
isn't even clear when it happens because it's just not something that any
other compiler would error on. It isn't about being able to fix it, it about
creating an assanine hurdle for anyone trying the language for the first time
in windows. No other compiler or scripting language makes someone jump through
that hoop. It is completely ridiculous. I still can not believe anyone would
defend this decision. Do you want people to use it or not?

~~~
jsjolen
I have no issue with that decision at all and find it akin to Go forcing users
to adhere to gofmt, and I don't use Zig. A good error message would be nice
(EDIT: A zigfmt would be even better).

How many developers who try out new languages are even using Windows? I'd
imagine most are on a UNIX-like. Regardless, I don't think it's a big deal
either way. You could always make a merge request with a fix if you feel so
strongly about it.

------
JyB
I'm so glad we are seeing a shift towards language simplicity in all aspects
(control flows, keywords, feature-set, ...). It'so important in ensuring
reliable codebases in general.

~~~
woodrowbarlow
i would love to see a shift towards small languages, which is subtly different
from a shift towards simple languages.

there are plenty of things i feel are serious shortcomings of C (mixing error
results with returned values is my big one), but the fact that the set of
things the language can do is small and the ways you can do them are limited
makes it much easier to write code that is easy to read. and that will always
keep me coming back.

------
mncharity
> uses a sophisticated caching system to avoid needlessly rebuilding artifacts

Reminded me of the Stanford Builder gg[1], which does highly parallel gcc
compilation on aws lambda. make -j2000.

So with a zig cc drop-in, you might get highly-parallel cross-compilation?

Though the two caching systems might be a bit redundant.

[1] [https://github.com/StanfordSNR/gg](https://github.com/StanfordSNR/gg)

------
peter_d_sherman
"In order to provide libc on these targets, Zig ships with a subset of the
source files for these projects:

musl v1.2.0

mingw-w64 v7.0.0

glibc 2.31"

These are super-important... (Otherwise, someone will be very limited in what
they can compile -- the simplest of programs only...).

It's great that you included these, and as source, not as precompiled
binaries!

(Also, a well-selected subset is probably the right balance of functionality
vs. complexity...)

Anyway, very excited about the future of Zig as a drop-in Clang/gcc
replacement!

------
chronogram
Perhaps I missed this from the blog post since it's unfamiliar to me. Can you
compile Linux with this? Like, could you really straight up use this is a
drop-in replacement for a whole Gentoo system?

~~~
AndyKelley
I'm guessing the build system of Linux depends on more than just a C compiler,
and that's why the answer to the question is "no". If the build system of
Linux only depends on a C compiler then my answer would be:

That would be a nice stress test, which would undoubtedly lead to bugs
discovered. After enough bugs fixed, the answer would be "yes".

I'll try it!

~~~
chronogram
Exciting! This is almost what I was thinking would be lovely about one month
ago when I was last hacking on C.

------
eatonphil
Wow, that's one of the easiest ways I've seen to get a C compiler for RISC-V.
Going on my list for when I'm playing around with emulators again.

------
speps
Zig is great and I can't wait to try cc! However, Andrew if you're reading
this, the std is very confusingly named. It's not a hash map, it's
AutoHashMap, it's not a list, it's a ArrayList, etc. I had a lot of trouble
finding idiomatic code without having to search through the std sources, like
an example with each struct/fun doc would help a ton.

~~~
tsimionescu
To be fair, 'list' is such a generic term it's not really useful. ArraList and
LinkedList and even a hash table are all examples of lists, but their
performance characteristics vary so wildly that it doesn't make sense to call
any of them simply 'list'.

------
nrclark
Zig looks super cool. I've been wanting to experiment with it for some system
software.

Are there any guides anywhere for calling libc functions from zig? I'm
interested in fork/join, chmod, fcntl, and that kind of thing. Do I just
import the C headers manually? Or is there some kind of built-in libc binding?

~~~
dnautics
I think you can call libc by importing the C headers "automagically" but zig
does also give you some of these things in its (admittedly still poorly
documented) std lib:

std.os.fork:
[https://github.com/ziglang/zig/blob/master/lib/std/os.zig#L2...](https://github.com/ziglang/zig/blob/master/lib/std/os.zig#L2732)
std.os.fcntl:
[https://github.com/ziglang/zig/blob/master/lib/std/os.zig#L3...](https://github.com/ziglang/zig/blob/master/lib/std/os.zig#L3173)

------
saagarjha
I read through the post but I'm still a bit confused as to what parts of this
is Zig and what parts are coming from other dependencies. What exactly is zig
cc doing, and what does it rely on existing? Where are the savings coming
from? Some people are mentioning that this is a clang frontend, so is the
novelty here that zig cc 1. passes the the correct options to clang and 2.
ships with recompilable support libraries (written in Zig, with a C ABI) to
statically link these correctly (or, in the case of glibc, it seems to have
some reduced fileset that it compiles into a stub libc to link against)? Where
is the clang that the options are being passed to coming from? Is this a
libclang or something that Zig ships with? Does this rely on the existence of
a "dumb" cross compiler in the back at all?

~~~
thristian
To compile C code, you need a bunch of different things: headers for the
target system, a C compiler targetting that system, and a libc implementation
to (statically or dynamically) link against. Different libc implementations
are compatible with the C standard, but can be incompatible with each other,
so it's important that you get the right one.

Cross-compiling with clang is complex because it's just a C compiler, and
doesn't make assumptions about what headers the target system might use, or
what libc it's using, so you have to set all those things up separately.

Zig is (apparently) a new language built on Clang/LLVM, so it can re-use that
to provide a C compiler. It also makes cross-compilation easier in two other
ways. First, it limits the number of supported targets - only Linux and
Windows, and on Linux only glibc and musl, and all supported on a fixed list
of the most common architectures. Second, building Zig involves pre-compiling
every supported libc for every supported OS and architecture, and bundling
them with the downloadable Zig package. That moves a _lot_ of work from the
end user to the Zig maintainers.

Like most magic tricks there's no actual magic involved, it's just somebody
doing more and harder work than you can believe anyone would reasonably do.

~~~
saagarjha
Does the LLVM toolchain that comes with Zig include cross-compilation support?
Is that what it is using?

~~~
daurnimator
Yes.

------
pierrebai
In the Zig main page, there is a claim that making overflow undefined on
unsigned can allow more optimization... but the example given is extremely
dependent on the constant chosen. Try to change the 3/6 used in C++ to 2/4,
3/8 and 4/8 for example... It is very strange how the clang code generation
changes for each pair of constants!

(Also, having undefined behaviour on unsigned overflow can make some bit
twiddling code harder to write. Then again, maybe Zig has a bit-twiddling
unsigned-like type without overflow check? Zip allow turning off checks, but
then it turns off checks for everything...)

------
ojosilva
I really love Zig, it can apparently replace our C toolchain with brilliant,
static cross-compilation, including s390 Linux support (mainframe Linux!).

My only gripe is that the syntax and stdlib, although practical and to the
point, seem to suffer from some strange choices that somewhat clash with its
own, albeit early, "zen" of simplicity.

\- '@' prefix for builtin functions, a little strange and macro-looking for my
eyes. Why not just plain keywords? And cleanup some of it: `@cos`, `@sin`,
also feel like too much when they are already in the stdlib I believe.

\- |x| for/while list bind var, why not just for(x in y)? Surrounding pipes
are really annoying to type in some foreign keyboards and feel totally
needless in 99% of the places.

\- inconsistent required parenthesis predicates in block statements in "test
STR {}" vs. "if() {}". Either require parenthesis or don't, I don't really
care which one.

\- prefixed type signatures, `?[]u32` feels a little off / harder to read.

\- comment-looking, noisy prefixed multi-line slashes `\\\\`.

\- the need to dig deep into "std" to get your everyday lib functions out
"std.io.getStdOut().outStream().print()". `@import("std")` repeated many
times.

\- consider implementing destructuring syntax early-on to deal with so much
struct member depth ie `const { x, y } = p` or `const { math: { add, mul } } =
@import("std")`.

\- anonymous list syntax with `.{}` is eye catching as the dot implies "struct
member" in Zig, but then the dot is everywhere, specially when you do
anonymous structs `.{.x=123}`, maybe consider `[1,2,3]` and `[x=123]` given
brackets are being used for array length annotation anyways ie `array[]`.

\- `. _` suffix for lvalue and rvalue pointer deref. Also ` "str"._` is a byte
array unroll if I understood correctly. Here `f.* = Foo{ .float = 12.34 };`
looks like it's doing something with `.` to get to the struct members but it's
actually just a pointer deref. Also looks like a file or import lib wildcard
(`file.*`) to my eyes.

\- field access by string clunky `@field(p, "x") = 123;`, with an odd function
as lvalue.

Sorry for the criticism, we're seriously checking out Zig for migrating a
large C codebase and replacing future C projects. Although we can live with
these quirks, they just make the language look a little random and NIH and
that worries me and the team. For instance, Golang has great syntax and
semantic consistency which is a boost on project steering quality and assured,
life-long onboarding for newbees. Please consider widening the spec peer-
review process, maybe in a separate Github repo with markdown proposal
writeups. Discussing syntax seems superficial given many project and compiler
feats under the hood, but it can become sorta "genetic disease" and a deal-
breaker for the project on the long run!

This is a pre-release version I know, but it's just that my hopes are really
up for Zig as Golang, C++ and Rust never really did it for us as a multi-
target sw toochain for various reasons.

~~~
speps
No for loops with a constant count is also a very strange choice

    
    
        for (([100]void)(undefined)) |_, verb| {
    

And I've been bitten multiple times with line endings having to be \n only.

~~~
jessermeyer
While I agree it's jarring to adjust to Zig's purpose of a for loop (iterate
over collections), the syntax here is really pushing you, consciously, to
adopt while loops instead. The only snag is that the invariant lives outside
the scope of the while, which feels bad.

------
Ericson2314
Because you are using nixpkgs...

~~Does `zig cc` cross compiler libgcc/compiler-rt on the fly? Does it compile
libc on the fly?~~ Nevermind I did not scroll enough, it does compile on the
fly. Whew!

As someone who also cares greatly about cross compilation, compilers
definitely should step up their game, but `-target x86_64-windows-gnu` elides
many details, unless you are confined to a fix set of platforms.

------
naasking
This looks impressive. Cross-compilation is sorely underserved. I will
definitely be checking this out.

------
rustybolt
I'm normally not an 'oh my god'-kind-of-guy, but... Oh my god!

Zig looks like a nice language for kernel development as well:
[https://github.com/jzck/kernel-zig](https://github.com/jzck/kernel-zig)

------
fwsgonzo
Looks very cool! Did not see 32-bit RISC-V on the list though, so wondering
about that. I would have liked to use Zig cc to build 32-bit RISC-V binaries
fast, if that is possible. Doesn't matter if they are freestanding.

~~~
AndyKelley
You can indeed use zig to make riscv32-freestanding binaries (in both zig and
C). What is not available is `-lc` for this target.

------
SaxonRobber
How does Zig compare with Nim and Rust? (putting aside the differences in
adoption)

~~~
rhodysurf
Manual memory management is the most important difference

------
presiozo
Damn, what an awesome project! That's a lot of hard work, and now I want to
try Zig. One more oh god save me from programming languages.

------
Y_Y
What are the limitations? Speed? External libraries?

~~~
ifreund
Afaik the only drawback is that this functionality is very new and still has
some open issues (linked at the end of the post). As stated there are no
dependencies for Zig and it is shipped in relatively small tarballs which can
be downloaded from the Zig website:
[https://ziglang.org/download/](https://ziglang.org/download/)

------
cbmuser
Why is there a sparc backend but no sparc64 backend? sparc64 is what Debian
uses these days, so having support for it in Zig would be nice.

------
keithnz
can zig compile to C? so many languages would be very useful if they could
compile to C for embedded systems as native compilers are very unlikely for
new ( or even old ) languages

~~~
hryx
Compiling to C source isn't planned for the reference Zig compiler, as far as
I know. It's more interested in helping people moving people off of C (see
`zig translate-c`).

But for supporting more esoteric targets you might be interested in the goals
of this ultra-early-stage assembler. ("Planned targets: All of them.")

[https://github.com/andrewrk/zasm](https://github.com/andrewrk/zasm)

~~~
haberman
As a (part-time) C programmer, I wouldn't really consider a "C replacement"
that can't compile to C. Part of the appeal of C is that it's easy to
integrate into other projects, regardless of the build system or obscure
hardware it might be targeting. If you require a compiler for a language few
people have heard of (even a very cool language), it seriously limits your
potential user-base.

If you tell me that I can write better, safer code by using Zig, but I can
also compile it into a .c artifact that anybody can use, now _that_ is a
tempting proposition!

~~~
pornel
Unless you really really need obscure platforms, just forget about it. Make
the jump, don't look back.

After you get a taste of a modern toolchain (with cross-compilation,
dependency management, but withou not-quite-portable build files to endlessly
fiddle with, without outdated compilers to work around), you will not want to
have to compile a C file again.

Languages like Zig and Rust are easy to install. Mostly it's just a tarball,
so it's less of an inconvenience than getting the right version of autotools.

~~~
keithnz
its not obscure platforms, its a ton of embedded platforms (you may consider
that obscure, but reality is there are millions and millions of devices out
there running software on these "obscure" platforms), most of them don't have
many options. At one stage I was writing write my own language to compile to C
based around state machines and actors as so many devices tend to be some
version (often badly implemented) of those two things. But I ended up moving
out of the embedded world and kind of lost my prime motivation for doing it.

------
jedisct1
Can `zig cc` also compile to WebAssembly/WASI?

~~~
yellowapple
Zig itself does support cross-compiling to WASM/WASI
([https://ziglang.org/documentation/master/#WebAssembly](https://ziglang.org/documentation/master/#WebAssembly)),
so there's surely some way to coax 'zig cc' into doing the same (though I
haven't tried it).

------
fizixer
llvm is a bloated hot-mess of a compilation framework, built on a bloated hot-
mess of a language (C++).

Folks who have achieved great things with llvm (and C++) have done so
'despite' what they used, not 'because of' it.

This has been my conviction for the past 10 years, and I'm glad I never had to
touch llvm with a ten foot pole.

I had no doubts it'll soon be surpassed by a common-sense no-bullshit tool-
chain.

Has Zig cc achieved that? Great. No? It will or someone (or I) will develop an
alternative that will.

~~~
saagarjha
> This has been my conviction for the past 10 years

I would suggest holding your convictions more loosely.

------
ngcc_hk
Wonder whether one can include this in iOS ...

------
spiritplumber
You know what you doing! Take off every zig!

------
throwaway_pdp09
I don't want to be negative as there's too much of that about but gcc and
similar can do some pretty hefty optimisations, and for any real work I
suspect those count for a great deal. Just because zigcc can compile C, neat
as it is, doesn't make it a drop-in replacement for gcc.

Does yours do loop unrolling, code hoisting, optimise array accesses to
pointer increments, common expression elimination etc?

~~~
lisper
Zig uses clang on the back-end, so while IANA compiler expert, I suspect it
does all these things.

