Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig's New Relationship with LLVM

kristoff.it

Post reply on HN
Print view View original

251–260 of 295 posts

Re: Zig's New Relationship with LLVM

#251

Post by dang »

yamirui wrote: post #232
gravitas wrote: post #54

Earlier quoted context omitted.

Thank you (for both replies) and to everyone else, this makes it crystal clear what's going on - there's a lack of "hey everyone, this is very unstable at the moment and the basic internals are changing, using anything except the latest Github builds is highly discouraged" which might really help when added to the various places above. I'm a toe-dipper -- I need to run and play with some sample code (basic Hello, Wor…

The only thing that's lacking is your understanding of semver. Zig is currently 0.6.0, you see that first number? This alone is a clear indication that nothing is truly stable and anything can disappear at any time for any reason.

This comment breaks the site guidelines. Please don't cross into personal attack in comments here, or generally be unkind or snarky.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and sticking to the rules when posting here, we'd be grateful.

Re: Zig's New Relationship with LLVM

#252

Post by est31 »

Guvante wrote: post #171
sai_c wrote: post #133

Earlier quoted context omitted.

At this point in time, i agree with this analysis. But what for a C programmer (systems/embedded) remains to be seen, is, if any of the new languages (say for example Rust, Zig, Odin) can (or want to) offer one of C's strengths most language designers do not think of (at least it looks to me like that). And this would be for me "leave the language alone (for the most part)". If i may quote from Zig's website ( https:…

Rust has editions to help with this. All code is backwards compatible (except soundness bugs) and if need be editions are added to allow adding breaking changes. The compiler still supports 2015 edition and will forever. You can even use different editions in the same project by importing crates that use a different edition, still overall creating a single binary. As an example of this one of the features they added…

You are still forced to upgrade your edition if you want to use certain libraries. I wanted to the newest versions of some async libraries and the update forced me to update my edition, otherwise I wouldn't have been able to use the libraries as they required me to use the async language feature.

Also, editions are no response to the issue of new features being added to the language, changing what is considered idiomatic, okay, etc. If Rust turns out to evolve constantly like C++ has in the past, then it'll be hard to keep up with it, in addition to the great one time cost of learning it in the first place.

Re: Zig's New Relationship with LLVM

#253

Post by ndesaulniers »

nick_ wrote: post #46
kristoff_it wrote: post #14

Earlier quoted context omitted.

LLVM is still going to be used for release builds. As of now, the self-hosted backend is dedicated to producing debug builds without optimizations (and with a few extra runtime inefficiencies, as that's the price for faster in-place binary replacement).

Thanks, that's the answer to my question :) Do you know if there has been any plans to implement this build-time optimization upstream in LLVM itself? Perhaps after it's been completed within Zig.

We started looking at build times of the Linux kernel with Clang this summer. Turns out that compile times are dominated by Clang, not LLVM. Sounds like different experiences for different frontends.

Re: Zig's New Relationship with LLVM

#254

Post by ndesaulniers »

MaulingMonkey wrote: post #55
benesch wrote: post #26

Yes, yes, yes, yes, yes. I'm going to make the kind of prediction that will set me up to be the laughingstock of HN in a few years. I think in-place binary patching will be the single most consequential development in build toolchains in the last twenty years; the most consequential development since a graduate student at the University of Illinois named Chris Lattner decided to embark on LLVM. If Zig is successful i…

Gold is much better than a 30% speedup IME. I went from >60 seconds per (config x arch x platform x near-leaf binary) combination with bfd, to 6x faster / Additionally, I'll note that gold's incremental linking is in-place binary patching, from what I can tell, and potentially another order-of-magnitude speedup even on your existing C projects - slide 11+ certainly appears to be describing such, and the caveats + res…

Have you tried LLD; LLD beat the crap out of Gold IME.

Re: Zig's New Relationship with LLVM

#255

Post by steveklabnik »

est31 wrote: post #252
Guvante wrote: post #171

Earlier quoted context omitted.

Rust has editions to help with this. All code is backwards compatible (except soundness bugs) and if need be editions are added to allow adding breaking changes. The compiler still supports 2015 edition and will forever. You can even use different editions in the same project by importing crates that use a different edition, still overall creating a single binary. As an example of this one of the features they added…

You are still forced to upgrade your edition if you want to use certain libraries. I wanted to the newest versions of some async libraries and the update forced me to update my edition, otherwise I wouldn't have been able to use the libraries as they required me to use the async language feature. Also, editions are no response to the issue of new features being added to the language, changing what is considered idiom…

What specifically made you need to? Editions aren’t supposed to make you do that. I would be interested in hearing what we missed!

Re: Zig's New Relationship with LLVM

#256

Post by pron »

chubot wrote: post #168
setpatchaddress wrote: post #152

Earlier quoted context omitted.

They are very effective, but relatively difficult to use.

They're built into both GCC and Clang and very easy to use IMO. The only hard part is figuring out how to pass -fsanitize=address into your compiler via your complex build system! And building with symbols. That is inherent to the C/C++ toolchain and not a problem that sanitizers can address.

Just to be clear, Zig isn't the same as C/C++ with sanitizers. Zig has slices and it doesn't have pointer arithmetic and pervasive casts. For example, if you preallocate a buffer and then reuse it, or chunk it into multiple pieces, sanitizers won't find an issue, but Zig will (thanks to slices). C simply has no way to express, "I want to pass a pointer into an array to this subroutine but it is only allowed to use n elements," when n is dynamic.

Re: Zig's New Relationship with LLVM

#257

Post by Johanx64 »

UncleOxidant wrote: post #147
pron wrote: post #52

Zig is one of the most interesting languages I've seen in a very long time, and possibly the first radical breakthrough in low-level programming design in decades. Maybe it will become a big success and maybe it will tank, but after having two visions for low-level programming -- that of C's "syntax-sugared Assembly", or that of C++'s "zero-cost abstractions" whose low-level, low-abstraction code appears high level o…

Tend to agree, but I hope that the zig folks aren't biting off too much by trying to replace LLVM. Sure, I can understand some of their reasons, but LLVM provides all kinds of functionality (optimization, code lowering, targeting lots of cpus,etc.) that will be difficult and time consuming to replace. I hope this doesn't cause them to lose focus on the development of the language itself and libraries.

*Replacing llvm in debug builds and similar where incremental build times are the most crucial

Fully optimized release builds will surely still have an option to use LLVM

Re: Zig's New Relationship with LLVM

#258

Post by alexithymia »

sai_c wrote: post #155
cashsterling wrote: post #148

Earlier quoted context omitted.

My 0.02... and have an upvote for stating your opinion. C is not going any where.. we all know that. But it is not the best tool for accomplishing many systems programming tasks. IMO, this has probably been true since Ada95. Ada2012/SPARK, Rust, and probably Zig make this even more clear. For some domains, C was the ONLY tool available... e.g. C is/was the only language with board-level support and an available compi…

Yes indeed, Ada/SPARK would be better suited, but suffer (unfortunately) from a hefty price tag, not every shop is willing to pay. Especially if there are no lifes at stake should your software crash. Rust has the (imo) above stated problem. Also, if you avoid dynamic allocation, Rust's advantages are not as compelling in the real world as advertised (personal opinion). They are there, but IMO minor. The problem righ…

When you say Ada has a hefty price tag, what do you mean, exactly?

(Are you talking about ide licences, the commercially supported version of the compiler, ramp-up time to productiveness, or maybe something else?)

Somehow I've become interested in the economics of Ada, and am considering it in comparison to several other strongly typed systems programming languages for a learning project. So I'm a bit curious.

Re: Zig's New Relationship with LLVM

#259

Post by pabs3 »

AndyKelley wrote: post #223
pabs3 wrote: post #60

I wonder how this will affect Zig's bootstrappability from source. https://bootstrappable.org/

https://github.com/ziglang/zig-bootstrap

Hmm, since the LLVM/Clang/Zig files in that repo are unmodified, why not just move the zig-bootstrap build script to a bootstrap script in the zig repository?

Re: Zig's New Relationship with LLVM

#260

Post by AndyKelley »

pabs3 wrote: post #259
AndyKelley wrote: post #223

Earlier quoted context omitted.

https://github.com/ziglang/zig-bootstrap

Hmm, since the LLVM/Clang/Zig files in that repo are unmodified, why not just move the zig-bootstrap build script to a bootstrap script in the zig repository?

what purpose would that serve?
Post reply on HN