[HN Gopher] Zig cc: A drop-in replacement for GCC/Clang
___________________________________________________________________
Zig cc: A drop-in replacement for GCC/Clang
Author : hazebooth
Score : 213 points
Date : 2020-03-24 21:19 UTC (1 hours ago)
(HTM) web link (andrewkelley.me)
(TXT) w3m dump (andrewkelley.me)
| chronogram wrote:
| 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 wrote:
| 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.
| AndyKelley wrote:
| 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 wrote:
| Exciting! This is almost what I was thinking would be lovely
| about one month ago when I was last hacking on C.
| emmanueloga_ wrote:
| 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
| est31 wrote:
| 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 wrote:
| 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.
| eatonphil wrote:
| 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.
| mncharity wrote:
| > 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 may be a bit redundant.
|
| [1] https://github.com/StanfordSNR/gg
| Y_Y wrote:
| What are the limitations? Speed? External libraries?
| ifreund wrote:
| 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/
| audunw wrote:
| 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.
| Shoop wrote:
| 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 [2]
| https://www.youtube.com/watch?v=5S2YArCx6vU
| Wowfunhappy wrote:
| Linux and GCC today have the ability to compile and run fully
| static executables, I don't understand why this isn't done...
| mehrdadn wrote:
| > 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 rebuild
| & push a new release.
| otterley wrote:
| 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.
| MereInterest wrote:
| Some of us use linux as a desktop environment, and like
| having the security patches be applied as soon as the
| relevant package has updated.
| [deleted]
| AndyKelley wrote:
| 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
| cycloptic wrote:
| 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 wrote:
| 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 wrote:
| 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!
| [deleted]
| drfuchs wrote:
| Zig (the language) is very appealing as a "better C than C".
| Check out https://ziglang.org (dis-disclaimer: I'm unaffiliated.)
| agapon wrote:
| 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 wrote:
| I mean, is this C-like? fn add(a: i32, b:
| i32) i32 { return a + b; }
| AndyKelley wrote:
| Yes: https://godbolt.org/z/72Dvpe
| [deleted]
| ifreund wrote:
| 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 wrote:
| 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 wrote:
| 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). 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 wrote:
| 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.
| jjnoakes wrote:
| 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 wrote:
| There is a semi-maintained (perhaps more accurately
| "occasionally resurrected") C backend for LLVM:
| https://github.com/JuliaComputing/llvm-cbe
___________________________________________________________________
(page generated 2020-03-24 23:00 UTC)