21 ms·

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

831 points by hazebooth 7y ago

deleted 7y ago
[deleted]
drfuchs 7y ago
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 7y ago
  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).
  - d4mi3n 7y ago
    IMO the marketing as Rust as a C/C++ replacement is a bit misplaced. I think it's more accurate to consider it an alternative systems language. The tools/languages used in this space are a bit broader than C-family languages.
    - ifreund 7y ago
      That's true, though systems programming is in practice dominated by the C ABI (great post on that here by the way https://drewdevault.com/2020/03/03/Abiopause.html https://drewdevault.com/2020/03/03/Abiopause.html). Zig does something quite special that puts it ahead of the crowd in this space; It can import and use C libraries as easily as C does (no bindings required), and it can itself be built into a C library, auto-generating the required C headers.
      - d4mi3n 7y ago
        You are absolutely correct on the point of the C ABI. It's definitely the systems lingua franca. Just finished reading the Zig cc article and I must say I'm also quite impressed. I'll be keeping an eye on the next Zig release--being able to eventually use it as a `cc` or `mvsc` replacement would be a big game changer. Having recently run the study of trying to cross compile a few C++ and GTK apps, I can really see the appeal.
  - stjohnswarts 7y ago
    I know it's not as complicated as C++ but it sure seems like they're in a rush to get there :) . Modern (post c++14) covers most of my criticisms of c++ for my daily driver. I still poke at Rust because I really love statically typed languages :)
    - yarrel 7y ago
      I've been very surprised by Rust's complexity. Some of it seems to be being hidden over time (as well as adding new features) but its syntax at any given moment is generally more complex than C++.
      - saagarjha 7y ago
        Really? I would consider its syntax to be of similar complexity but of higher consistency. What parts of it do you find complex?
        pjmlp 7y ago
        When you happen to have generics coupled with lifetime annotations for example.
    - throwaway17_17 7y ago
      I’m not being contrarian, but I have only been following Zig in passing. Can you give a few example of the increase in complexity, I am genuinely curious. Zig seems, to my eyes at least, to have done an admirable job of remaining simple when compared to the behemoth that is C++, of any vintage (but especially post C++03).
  - LessDmesg 7y ago
    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.
    - otabdeveloper2 7y ago
      > It targets its own niche (embedded, realtime, correctness-oriented). I don't know of anyone who actually uses Rust in that niche. Everyone who uses Rust is using it because of "C++ is hard, let's go shopping instead" syndrome. I.e., at this point it's a language for beginners to ease themselves into programming without training wheels and eventually graduate to real big boy programming languages.
      - smolder 7y ago
        This is a strange sentiment. I think 99/100 people who know rust would not categorize it as "for beginners"
        otabdeveloper2 7y ago
        It's pretty much irrelevant what people feel emotionally about Rust. The real-world fact is that Rust is, as of March 2020 at least, an entry-level systems programming language. It's used as a stepping stone by former PHP/Python/Go programmers, who are very intimidated by C++, to get into performance-oriented coding. Nobody actually writing embedded or sensitive code (airplanes, nuclear power stations, etc.) is doing it in Rust.
        dystroy 7y ago
        This makes zero sense and it's not about emotion. The language is young and you don't certify a software solution every two days or don't rewrite your nuclear power station code every day. Very experienced programmers switched to Rust because it makes it possible to build large scale industrial programs both efficient and reliable. They won't switch to C++ just because they think they're good enough to live dangerously. (btw I work on plant control and yes I write parts in Rust)
- agapon 7y ago
  I don't know... To me, zig does not look like C at all. IMO, go and zig are as similar to each other as they are dissimilar to C.
  - agapon 7y ago
    I mean, is this C-like? fn add(a: i32, b: i32) i32 { return a + b; }
    - AndyKelley 7y ago
      Yes: https://godbolt.org/z/72Dvpe https://godbolt.org/z/72Dvpe
      - iruoy 7y ago
        Simple stuff like this looks very similar to Rust: https://godbolt.org/z/spkKai https://godbolt.org/z/spkKai Rust quickly becomes harder though, while Zig is much easier to grasp.
      - tsimionescu 7y ago
        The fact that they compile to the same assembly instruction does not make them similar source code.
        tzjmetron 7y ago
        Semantics vs syntax.
        abainbridge 7y ago
        The languages are similar enough that the Zig tool-chain can translate C source into Zig source. There's mostly a one-to-one correspondence.
        tzjmetron 7y ago
        To be fair, that's not really a very strong point, is it? Any language can be translated into C via an appropriate transpiler.
- jjnoakes 7y ago
  I wonder how much it would cost to sponsor compiles-via-c support. I'd love to use zig-the-language but I need to compile for platforms that LLVM does not support, so I would need to use the native C toolchain (assembler/linker at the least, but using the native C compiler seems easier).
  - ihnorton 7y ago
    There is a semi-maintained (perhaps more accurately “occasionally resurrected”) C backend for LLVM: https://github.com/JuliaComputing/llvm-cbe https://github.com/JuliaComputing/llvm-cbe
    - jjnoakes 7y ago
      Thanks; I was aware of this but last I checked it only supports a subset of LLVM (whatever Julia needed).
- ndesaulniers 7y ago
  > (dis-disclaimer: I'm unaffiliated.) https://ziglang.org/#Sponsors https://ziglang.org/#Sponsors > drfuchs oh, ok
- boltzmann_brain 7y ago
  On a first glance, it does look like a simpler version of Rust, and I say it without demeaning Zig. Looks very promising, I'll be keeping an eye for it.
- pjmlp 7y ago
  I am still not sold on its security story, usage of @ and module imports.
  - skrebbel 7y ago
    Can you elaborate on the security story story?
    - pjmlp 7y ago
      Manual memory management, we have already learned that isn't the way to go, when security is part of the requirements in a connected world. Still no way to catch use-after-free. https://github.com/ziglang/zig/issues/3180 https://github.com/ziglang/zig/issues/3180
      - skrebbel 7y ago
        Clear, good point, thanks.
eatonphil 7y ago
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.
Y_Y 7y ago
What are the limitations? Speed? External libraries?
- ifreund 7y ago
  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/
- audunw 7y ago
  The limitation is maturity/stability I'd say. Zig is still pre-1.0 Speed? Using Zig should be faster than using Clang directly in many cases. You get the caching system, and I think you can do more complex builds without having to resort to multiple Clang commands from a makefile. Not sure what you mean with external libraries.
chronogram 7y ago
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?
- loeg 7y ago
  Historically the Linux kernel used GCC extensions that Clang did not support, and this is just a thin shim around the ordinary Clang frontend, so to the extent that's still a problem: no. Otherwise: yeah. It's just clang's main function with a different name slapped on. Linking semantics may differ slightly which could be problematic. But in theory, yes.
  - yjftsjthsd-h 7y ago
    > so to the extent that's still a problem: no. Clang can apparently build a vanilla Linux kernel now, no gotchas, actively used by Google for its Linux things (Android, chromeos).
    - ndesaulniers 7y ago
      Yep, check out clangbuiltlinux.github.io for more info!
    - loeg 7y ago
      Glad to hear it!
- AndyKelley 7y ago
  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 7y ago
emmanueloga_ 7y ago
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
- est31 7y ago
  Note that on linux hosts at least, for most target platforms, being able to cross compile with clang is only one single install of the right packages away.
- wyldfire 7y ago
  I think a problem comes when you want to distribute your compiler potentially independent from your OS and/or linker and/or C library. But it's also fair to say that if we had always considered those things as inseparable parts of the "compiler suite" that might have made everyone better off.
- ncmncm 7y ago
  Portability depends on a great deal more than just object code formats. The list of OS environment functions to call to achieve anything useful is radically different from one target to another. This is what makes porting hard work. Cross-compiling is only the first step of a long trip.
- Hello71 7y ago
  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.
mncharity 7y ago
> 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
Shoop 7y ago
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 7y ago
  Linux and GCC today have the ability to compile and run fully static executables, I don't understand why this isn't done...
  - dataflow 7y ago
    > I don't understand why this isn't done Because when there's a security update to (say) OpenSSL, it's better for the maintainers of just that library to push an update, as opposed to forcing every single dependent to rebuild & push a new release.
    - otterley 7y ago
      I would have agreed with this statement about five years ago. (Even though you would have had to restart all the dependent binaries after updating the shared libs.) Today, with containers becoming increasingly the de facto means of deploying software, it's not so important anymore. The upgrade process is now: (1) build an updated image; (2) upgrade your deployment manifest; (3) upload your manifest to your control plane. The control plane manages the rest. The other reason to use shared libs is for memory conservation, but except on the smallest devices, I'm not sure the average person cares about conserving a few MB of memory on 4GB+ machines anymore.
AndyKelley 7y ago
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
- cycloptic 7y ago
  Hi Andy, thanks for your hard work on this. I am not a Zig user/sponsor yet but hopefully I will be soon. It's looking better and better every month.
- cshenton 7y ago
  Thanks for all your effort on the project. By far my best experience with zig was writing an OpenGL renderer on windows which then “just worked” when I cloned it ran `zig build` on my Linux machine. Felt like magic.
- jftuga 7y ago
  For the 0.60 release, could you please provide a download for Raspberry Pi running Raspbian? On my RPi 4, 'uname -m -o' returns: armv7l GNU/Linux Thanks!
- acqq 7y ago
  It is amazing work, I'm so glad you invested your attention in this direction, kudos! I haven't used the language and the compiler yet but just reading the title article I almost jumped from joy, knowing how unexpectedly painful is to target different versions of system libraries on Linux.
- nikisweeting 7y ago
  It's been amazing following all the progress so far. I'm a proud $5/mo sponsor and look forward to writing something in Zig soon! Are there any concurrency constructs provided by the language yet? I'm just starting to learn how to do concurrency in lower-level langauges (with mutexes and spinlocks and stuff). I'm coming from the world of Python where my experience with concurrent state is limited to simple row-level locks and `with transaction.atomic():`. An equivalent article to this would be awesome for Zig: https://begriffs.com/posts/2020-03-23-concurrent-programming.html https://begriffs.com/posts/2020-03-23-concurrent-programming... Edit: I just found this announcement for async function support: https://ziglang.org/download/0.5.0/release-notes.html#Async-Functions https://ziglang.org/download/0.5.0/release-notes.html#Async-...
deleted 7y ago
[deleted]
throwaway_pdp09 7y ago
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 7y ago
  Zig uses clang on the back-end, so while IANA compiler expert, I suspect it does all these things.
- hobo_mark 7y ago
  Yes, it's clang under the hood.
- jeltz 7y ago
  This is just a new frontend for clang so it should use all the optimization passes of clang. The main new features are convenient cross compilation and better caching for partial compilation results.
speps 7y ago
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 7y ago
  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'.
- yellowapple 7y ago
  I reckon the point of the naming is to force you to think about exactly which behavior you want/need in your program, given that arrays and linked lists (for example) are very different from one another with very different performance characteristics. It's a bit unfortunate that (last I checked) there's no "I don't care how it's implemented as long as it's a list" option at the moment (e.g. for libraries that don't necessarily want to be opinionated about which list implementation to use). Should be possible to implement it as a common interface the same way the allocators in Zig's stdlib each implement a common interface (by generating a struct with pointers to the relevant interface functions).
fwsgonzo 7y ago
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 7y ago
  You can indeed use zig to make riscv32-freestanding binaries (in both zig and C). What is not available is `-lc` for this target.
airstrike 7y ago
> 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!
- fao_ 7y ago
  You can do that in clang/gcc but you need to pass: -static and -static-plt(? I can't find what it's called). The second option is to ensure it's loader-independent, otherwise you get problems when compiling and running across musl/glibc platforms
  - nh2 7y ago
    Could you elaborate/link on the loader-independency topic?
    - fao_ 7y ago
      In brief, most programs these days are position-independent, which means you need a runtime loader to load sections(?) and symbols of the code into memory and tell other parts of the code where they've put it. Because of differences between musl libc and gnu libc, in effect for the user this means that a program compiled on gnu libc can be marked as executable, but when they try to run it the user is told it is "not executable", because the binary is looking in the wrong place for the dynamic loader, which is named differently across the libraries. There are also some archaic symbols that gnu libc describes that are non-standard, which musl libc has a problem with, that can cause a problem for the end-user. e: I didn't realise it was 5am, so I'm sorry if it's not very coherent.
keithnz 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        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.
nrclark 7y ago
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 7y ago
  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#L2732 https://github.com/ziglang/zig/blob/master/lib/std/os.zig#L2... std.os.fcntl: https://github.com/ziglang/zig/blob/master/lib/std/os.zig#L3173 https://github.com/ziglang/zig/blob/master/lib/std/os.zig#L3...
- AndyKelley 7y ago
  For POSIX, you can use the standard library: std.os.chmod std.os.fcntl Better yet, use the higher level cross platform abstractions. For example instead of fork/join, std.Thread.create std.Thread.wait These will work in Windows as well as POSIX.
Ericson2314 7y ago
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.
fizixer 7y ago
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 7y ago
  > This has been my conviction for the past 10 years I would suggest holding your convictions more loosely.
- throwaway17_17 7y ago
  I’m not arguing that certain people using particular standards could consider LLVM bloated and I’m certainly not going to argue that by certain standards C++ could be considered bloated. But for users of LLVM, be it via clang or Zig cc or GHC, it seems to work just fine. Are your complaints from the perspective of a compiler dev (or a general dev who wants to be able to more easily open up and tune a compiler) or are they just as a user? Also, for native binary compilation of performance sensitive applications, how many options are there in common use for the major languages? Your opinion seems pretty severe, so I’m just trying to see why that is.
- yellowapple 7y ago
  > 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. Out of curiosity: what do you touch with a ten foot pole? I'd be hard-pressed to call GCC or MSVC much better in that regard, and I can think of very few others that are in use anymore. I mean, I've definitely dreamt about using SBCL or Clozure for things other than Lisp (seeing as they both include their own compilers not dependent on GCC/LLVM), but I've seen effectively zero effort in that direction.
spiritplumber 7y ago
You know what you doing! Take off every zig!
ngcc_hk 7y ago
Wonder whether one can include this in iOS ...
saagarjha 7y ago
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 7y ago
  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 7y ago
    Does the LLVM toolchain that comes with Zig include cross-compilation support? Is that what it is using?
cbmuser 7y ago
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.
deleted 7y ago
[deleted]
peter_d_sherman 7y ago
"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!
jedisct1 7y ago
Can `zig cc` also compile to WebAssembly/WASI?
- jedisct1 7y ago
  Apparently not :( Zig is unable to provide a libc for the chosen target 'wasm32-wasi-musl'
- yellowapple 7y ago
  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).
SaxonRobber 7y ago
How does Zig compare with Nim and Rust? (putting aside the differences in adoption)
- rhodysurf 7y ago
  Manual memory management is the most important difference
rustybolt 7y ago
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
ojosilva 7y ago
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.
JyB 7y ago
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 7y ago
  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.
presiozo 7y ago
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.
naasking 7y ago
This looks impressive. Cross-compilation is sorely underserved. I will definitely be checking this out.
pierrebai 7y ago
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...)
hardwaregeek 7y ago
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.

831 points by hazebooth 7y ago

deleted 7y ago

[deleted]

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 7y ago
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).
- d4mi3n 7y ago
  IMO the marketing as Rust as a C/C++ replacement is a bit misplaced. I think it's more accurate to consider it an alternative systems language. The tools/languages used in this space are a bit broader than C-family languages.
  - ifreund 7y ago
    That's true, though systems programming is in practice dominated by the C ABI (great post on that here by the way https://drewdevault.com/2020/03/03/Abiopause.html https://drewdevault.com/2020/03/03/Abiopause.html). Zig does something quite special that puts it ahead of the crowd in this space; It can import and use C libraries as easily as C does (no bindings required), and it can itself be built into a C library, auto-generating the required C headers.
    - d4mi3n 7y ago
      You are absolutely correct on the point of the C ABI. It's definitely the systems lingua franca. Just finished reading the Zig cc article and I must say I'm also quite impressed. I'll be keeping an eye on the next Zig release--being able to eventually use it as a `cc` or `mvsc` replacement would be a big game changer. Having recently run the study of trying to cross compile a few C++ and GTK apps, I can really see the appeal.
- stjohnswarts 7y ago
  I know it's not as complicated as C++ but it sure seems like they're in a rush to get there :) . Modern (post c++14) covers most of my criticisms of c++ for my daily driver. I still poke at Rust because I really love statically typed languages :)
  - yarrel 7y ago
    I've been very surprised by Rust's complexity. Some of it seems to be being hidden over time (as well as adding new features) but its syntax at any given moment is generally more complex than C++.
    - saagarjha 7y ago
      Really? I would consider its syntax to be of similar complexity but of higher consistency. What parts of it do you find complex?
      - pjmlp 7y ago
        When you happen to have generics coupled with lifetime annotations for example.
  - throwaway17_17 7y ago
    I’m not being contrarian, but I have only been following Zig in passing. Can you give a few example of the increase in complexity, I am genuinely curious. Zig seems, to my eyes at least, to have done an admirable job of remaining simple when compared to the behemoth that is C++, of any vintage (but especially post C++03).
- LessDmesg 7y ago
  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.
  - otabdeveloper2 7y ago
    > It targets its own niche (embedded, realtime, correctness-oriented). I don't know of anyone who actually uses Rust in that niche. Everyone who uses Rust is using it because of "C++ is hard, let's go shopping instead" syndrome. I.e., at this point it's a language for beginners to ease themselves into programming without training wheels and eventually graduate to real big boy programming languages.
    - smolder 7y ago
      This is a strange sentiment. I think 99/100 people who know rust would not categorize it as "for beginners"
      - otabdeveloper2 7y ago
        It's pretty much irrelevant what people feel emotionally about Rust. The real-world fact is that Rust is, as of March 2020 at least, an entry-level systems programming language. It's used as a stepping stone by former PHP/Python/Go programmers, who are very intimidated by C++, to get into performance-oriented coding. Nobody actually writing embedded or sensitive code (airplanes, nuclear power stations, etc.) is doing it in Rust.
        dystroy 7y ago
        This makes zero sense and it's not about emotion. The language is young and you don't certify a software solution every two days or don't rewrite your nuclear power station code every day. Very experienced programmers switched to Rust because it makes it possible to build large scale industrial programs both efficient and reliable. They won't switch to C++ just because they think they're good enough to live dangerously. (btw I work on plant control and yes I write parts in Rust)
agapon 7y ago
I don't know... To me, zig does not look like C at all. IMO, go and zig are as similar to each other as they are dissimilar to C.
- agapon 7y ago
  I mean, is this C-like? fn add(a: i32, b: i32) i32 { return a + b; }
  - AndyKelley 7y ago
    Yes: https://godbolt.org/z/72Dvpe https://godbolt.org/z/72Dvpe
    - iruoy 7y ago
      Simple stuff like this looks very similar to Rust: https://godbolt.org/z/spkKai https://godbolt.org/z/spkKai Rust quickly becomes harder though, while Zig is much easier to grasp.
    - tsimionescu 7y ago
      The fact that they compile to the same assembly instruction does not make them similar source code.
      - tzjmetron 7y ago
        Semantics vs syntax.
      - abainbridge 7y ago
        The languages are similar enough that the Zig tool-chain can translate C source into Zig source. There's mostly a one-to-one correspondence.
        tzjmetron 7y ago
        To be fair, that's not really a very strong point, is it? Any language can be translated into C via an appropriate transpiler.
jjnoakes 7y ago
I wonder how much it would cost to sponsor compiles-via-c support. I'd love to use zig-the-language but I need to compile for platforms that LLVM does not support, so I would need to use the native C toolchain (assembler/linker at the least, but using the native C compiler seems easier).
- ihnorton 7y ago
  There is a semi-maintained (perhaps more accurately “occasionally resurrected”) C backend for LLVM: https://github.com/JuliaComputing/llvm-cbe https://github.com/JuliaComputing/llvm-cbe
  - jjnoakes 7y ago
    Thanks; I was aware of this but last I checked it only supports a subset of LLVM (whatever Julia needed).
ndesaulniers 7y ago
> (dis-disclaimer: I'm unaffiliated.) https://ziglang.org/#Sponsors https://ziglang.org/#Sponsors > drfuchs oh, ok
boltzmann_brain 7y ago
On a first glance, it does look like a simpler version of Rust, and I say it without demeaning Zig. Looks very promising, I'll be keeping an eye for it.
pjmlp 7y ago
I am still not sold on its security story, usage of @ and module imports.
- skrebbel 7y ago
  Can you elaborate on the security story story?
  - pjmlp 7y ago
    Manual memory management, we have already learned that isn't the way to go, when security is part of the requirements in a connected world. Still no way to catch use-after-free. https://github.com/ziglang/zig/issues/3180 https://github.com/ziglang/zig/issues/3180
    - skrebbel 7y ago
      Clear, good point, thanks.

eatonphil 7y ago

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.

Y_Y 7y ago

What are the limitations? Speed? External libraries?

ifreund 7y ago
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/
audunw 7y ago
The limitation is maturity/stability I'd say. Zig is still pre-1.0 Speed? Using Zig should be faster than using Clang directly in many cases. You get the caching system, and I think you can do more complex builds without having to resort to multiple Clang commands from a makefile. Not sure what you mean with external libraries.

chronogram 7y ago

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?

loeg 7y ago
Historically the Linux kernel used GCC extensions that Clang did not support, and this is just a thin shim around the ordinary Clang frontend, so to the extent that's still a problem: no. Otherwise: yeah. It's just clang's main function with a different name slapped on. Linking semantics may differ slightly which could be problematic. But in theory, yes.
- yjftsjthsd-h 7y ago
  > so to the extent that's still a problem: no. Clang can apparently build a vanilla Linux kernel now, no gotchas, actively used by Google for its Linux things (Android, chromeos).
  - ndesaulniers 7y ago
    Yep, check out clangbuiltlinux.github.io for more info!
  - loeg 7y ago
    Glad to hear it!
AndyKelley 7y ago
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 7y ago

emmanueloga_ 7y ago

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

est31 7y ago
Note that on linux hosts at least, for most target platforms, being able to cross compile with clang is only one single install of the right packages away.
wyldfire 7y ago
I think a problem comes when you want to distribute your compiler potentially independent from your OS and/or linker and/or C library. But it's also fair to say that if we had always considered those things as inseparable parts of the "compiler suite" that might have made everyone better off.
ncmncm 7y ago
Portability depends on a great deal more than just object code formats. The list of OS environment functions to call to achieve anything useful is radically different from one target to another. This is what makes porting hard work. Cross-compiling is only the first step of a long trip.
Hello71 7y ago
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.

mncharity 7y ago

> 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

Shoop 7y ago

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 7y ago
Linux and GCC today have the ability to compile and run fully static executables, I don't understand why this isn't done...
- dataflow 7y ago
  > I don't understand why this isn't done Because when there's a security update to (say) OpenSSL, it's better for the maintainers of just that library to push an update, as opposed to forcing every single dependent to rebuild & push a new release.
  - otterley 7y ago
    I would have agreed with this statement about five years ago. (Even though you would have had to restart all the dependent binaries after updating the shared libs.) Today, with containers becoming increasingly the de facto means of deploying software, it's not so important anymore. The upgrade process is now: (1) build an updated image; (2) upgrade your deployment manifest; (3) upload your manifest to your control plane. The control plane manages the rest. The other reason to use shared libs is for memory conservation, but except on the smallest devices, I'm not sure the average person cares about conserving a few MB of memory on 4GB+ machines anymore.

AndyKelley 7y ago

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

cycloptic 7y ago
Hi Andy, thanks for your hard work on this. I am not a Zig user/sponsor yet but hopefully I will be soon. It's looking better and better every month.
cshenton 7y ago
Thanks for all your effort on the project. By far my best experience with zig was writing an OpenGL renderer on windows which then “just worked” when I cloned it ran `zig build` on my Linux machine. Felt like magic.
jftuga 7y ago
For the 0.60 release, could you please provide a download for Raspberry Pi running Raspbian? On my RPi 4, 'uname -m -o' returns: armv7l GNU/Linux Thanks!
acqq 7y ago
It is amazing work, I'm so glad you invested your attention in this direction, kudos! I haven't used the language and the compiler yet but just reading the title article I almost jumped from joy, knowing how unexpectedly painful is to target different versions of system libraries on Linux.
nikisweeting 7y ago
It's been amazing following all the progress so far. I'm a proud $5/mo sponsor and look forward to writing something in Zig soon! Are there any concurrency constructs provided by the language yet? I'm just starting to learn how to do concurrency in lower-level langauges (with mutexes and spinlocks and stuff). I'm coming from the world of Python where my experience with concurrent state is limited to simple row-level locks and `with transaction.atomic():`. An equivalent article to this would be awesome for Zig: https://begriffs.com/posts/2020-03-23-concurrent-programming.html https://begriffs.com/posts/2020-03-23-concurrent-programming... Edit: I just found this announcement for async function support: https://ziglang.org/download/0.5.0/release-notes.html#Async-Functions https://ziglang.org/download/0.5.0/release-notes.html#Async-...

deleted 7y ago

[deleted]

throwaway_pdp09 7y ago

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 7y ago
Zig uses clang on the back-end, so while IANA compiler expert, I suspect it does all these things.
hobo_mark 7y ago
Yes, it's clang under the hood.
jeltz 7y ago
This is just a new frontend for clang so it should use all the optimization passes of clang. The main new features are convenient cross compilation and better caching for partial compilation results.

speps 7y ago

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 7y ago
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'.
yellowapple 7y ago
I reckon the point of the naming is to force you to think about exactly which behavior you want/need in your program, given that arrays and linked lists (for example) are very different from one another with very different performance characteristics. It's a bit unfortunate that (last I checked) there's no "I don't care how it's implemented as long as it's a list" option at the moment (e.g. for libraries that don't necessarily want to be opinionated about which list implementation to use). Should be possible to implement it as a common interface the same way the allocators in Zig's stdlib each implement a common interface (by generating a struct with pointers to the relevant interface functions).

fwsgonzo 7y ago

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 7y ago
You can indeed use zig to make riscv32-freestanding binaries (in both zig and C). What is not available is `-lc` for this target.

airstrike 7y ago

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

fao_ 7y ago
You can do that in clang/gcc but you need to pass: -static and -static-plt(? I can't find what it's called). The second option is to ensure it's loader-independent, otherwise you get problems when compiling and running across musl/glibc platforms
- nh2 7y ago
  Could you elaborate/link on the loader-independency topic?
  - fao_ 7y ago
    In brief, most programs these days are position-independent, which means you need a runtime loader to load sections(?) and symbols of the code into memory and tell other parts of the code where they've put it. Because of differences between musl libc and gnu libc, in effect for the user this means that a program compiled on gnu libc can be marked as executable, but when they try to run it the user is told it is "not executable", because the binary is looking in the wrong place for the dynamic loader, which is named differently across the libraries. There are also some archaic symbols that gnu libc describes that are non-standard, which musl libc has a problem with, that can cause a problem for the end-user. e: I didn't realise it was 5am, so I'm sorry if it's not very coherent.

keithnz 7y ago

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

nrclark 7y ago

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 7y ago
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#L2732 https://github.com/ziglang/zig/blob/master/lib/std/os.zig#L2... std.os.fcntl: https://github.com/ziglang/zig/blob/master/lib/std/os.zig#L3173 https://github.com/ziglang/zig/blob/master/lib/std/os.zig#L3...
AndyKelley 7y ago
For POSIX, you can use the standard library: std.os.chmod std.os.fcntl Better yet, use the higher level cross platform abstractions. For example instead of fork/join, std.Thread.create std.Thread.wait These will work in Windows as well as POSIX.

Ericson2314 7y ago

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.

fizixer 7y ago

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 7y ago
> This has been my conviction for the past 10 years I would suggest holding your convictions more loosely.
throwaway17_17 7y ago
I’m not arguing that certain people using particular standards could consider LLVM bloated and I’m certainly not going to argue that by certain standards C++ could be considered bloated. But for users of LLVM, be it via clang or Zig cc or GHC, it seems to work just fine. Are your complaints from the perspective of a compiler dev (or a general dev who wants to be able to more easily open up and tune a compiler) or are they just as a user? Also, for native binary compilation of performance sensitive applications, how many options are there in common use for the major languages? Your opinion seems pretty severe, so I’m just trying to see why that is.
yellowapple 7y ago
> 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. Out of curiosity: what do you touch with a ten foot pole? I'd be hard-pressed to call GCC or MSVC much better in that regard, and I can think of very few others that are in use anymore. I mean, I've definitely dreamt about using SBCL or Clozure for things other than Lisp (seeing as they both include their own compilers not dependent on GCC/LLVM), but I've seen effectively zero effort in that direction.

spiritplumber 7y ago

You know what you doing! Take off every zig!

ngcc_hk 7y ago

Wonder whether one can include this in iOS ...

saagarjha 7y ago

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 7y ago
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 7y ago
  Does the LLVM toolchain that comes with Zig include cross-compilation support? Is that what it is using?

cbmuser 7y ago

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.

deleted 7y ago

[deleted]

peter_d_sherman 7y ago

"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!

jedisct1 7y ago

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

jedisct1 7y ago
Apparently not :( Zig is unable to provide a libc for the chosen target 'wasm32-wasi-musl'
yellowapple 7y ago
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).

SaxonRobber 7y ago

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

rhodysurf 7y ago
Manual memory management is the most important difference

rustybolt 7y ago

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

ojosilva 7y ago

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.

JyB 7y ago

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

presiozo 7y ago

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.

naasking 7y ago

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

pierrebai 7y ago

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

hardwaregeek 7y ago

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.