Zig's New Relationship with LLVM • Hacker News Board

Re: Zig's New Relationship with LLVM

#121

Post by jhardy54 » Mon, Sep 28, 2020, 3:20 PM UTC

ikskuh wrote: post #47

gravitas wrote: post #32

I see zig users commenting here -- the "getting started" guide at https://ziglearn.org/ immediately fails with the installable zig binary from Arch (0.6.0) due to https://github.com/ziglang/zig/issues/5683 I'd never heard of zig until now, but as a community having top level "how to get started" website using features only available from the Master branch of github is... not a good way to get people into your languag…

Note that tagged releases in zig are just "the first state that worked with the new LLVM version". Imho it would be unreasonable to even try keeping backwards compatibility in a language that tries to find the global maximum > but geez this is a Hello, World sample that fails This is because the 0.7.0 release cycle changed a lot about logging: std.debug.warn was used as a general purpose log function in 0.6, but is n…

> Imho it would be unreasonable to even try keeping backwards compatibility in a language that tries to find the global maximum

What does this mean? I can't think of any way to interpret "find the global maximum" that applies to Zig but not other languages.

Re: Zig's New Relationship with LLVM

#122

Post by evmar » Mon, Sep 28, 2020, 3:20 PM UTC

zokier wrote: post #45

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…

This might be stupid question but would it make sense to forgoe linking a monolithic binary altogether and just load the different bits dynamically at startup from various object files or something like that? On the other hand your way of thinking sounds a lot like what I understand Smalltalk image format to be like

I wrote a sibling reply to this with some links on how I did this for the Chrome build, https://news.ycombinator.com/item?id=24617526 .

Re: Zig's New Relationship with LLVM

#123

Post by jedisct1 » Mon, Sep 28, 2020, 3:21 PM UTC

ikskuh wrote: post #15

pedrow wrote: post #10

This is interesting stuff. Could you comment about optimization? LLVM has put a lot of effort into optimizing code at various levels, including the LTO stuff. Will Zig match all this by itself, or will a 'Release mode' still use LLVM to produce a final version?

The overall idea is to have a selfhosted compiler for debug and release builds where the release build as ~80% of LLVM performance and use LLVM as an optional dependency to go 100% performance

The self-hosted compiler is only going to be for debug builds AFAIK.

Re: Zig's New Relationship with LLVM

#124

Post by nemo1618 » Mon, Sep 28, 2020, 3:21 PM UTC

higerordermap wrote: post #77

simias wrote: post #49

Earlier quoted context omitted.

Can you explain what you have in mind exactly? I'm very much a system programmer and very much not a webdev and I'm basically in love with Rust, so I'm not really sure why you feel that way. I admit that I don't know much about Zig and it does seem like a very interesting language, but at a glance it seems to me like the type system is significantly weaker than Rust's (which may be a good thing for compile times). Fo…

a strong type system in itself doesn't cause slowness in compiler. A large part of time is spent in code generator. Rustc produces lot of LLVM IR and it is mentioned there is some technical debt there. For systems languages I don't think dynamic dispatch instead of monomorphization is not the right way to implement generics. And zig doesn't seem to be doing dynamic dispatch either. It shouldn't affect the amount of c…

> I think having something built in is wrong, if it can be a library

I'm split on this one. This sort of "axiomatic" philosophy of programming is fairly common, and it's not hard to see why; it just feels right, intuitively, for everything to be built out of a tiny set of simple constructs. It's really empowering to know that, if you understand those constructs, you can (in principle) understand any program. Lisp and Urbit are extreme examples of this.

But to everything, there is a price, and here the price is paid in performance, tooling, and readability. Reified builtins can offend our sensibilities, but they are easier to optimize, permit deeper tooling, and require less cognitive overhead.

Ultimately, I think it's a man/machine distinction. It's like...lined paper. Printers don't need paper to be lined in order to "write" in straight lines. A human, if they're being really careful, doesn't either -- but it sure helps. Lined paper is designed by meatbags, for meatbags. The question to ask is, who's doing the writing? I don't know offhand, but I'd guess that lined paper is far less common now than it was 50 years ago. Maybe in 50 years, it will be similarly uncommon to see programming languages designed around arbitrary human sensibilities. But even after that, I think most humans will continue to prefer arbitrary languages.

Re: Zig's New Relationship with LLVM

#125

Post by dnautics » Mon, Sep 28, 2020, 3:23 PM UTC

higerordermap wrote: post #63

pron wrote: post #58

Earlier quoted context omitted.

Zig is (or will be) memory-safe -- selectively. It just achieves that in a way that's very different from Rust. The way Zig helps you write memory safe programs is by adding runtime checks that eliminate undefined behaviour. UB becomes a panic. However, in your production build, you can choose to selectively remove those checks from some or all of your subroutines. If you remove those checks, while Zig does not give…

More than that, people don't understand 'right tool for the job'. For not-so-reliability-critical pieces of software, eg game related, zig might be easier to get it done. Some people are really passionate about rust and very talented, they aren't affected by rust's non-zero cognitive overhead. But us trivial 1x programmers are.

Readabity is also critical for correctness in human systems. If you get lost and expend too much mental energy fighting the borrow checker, you might miss other errors. You might get overconfident that your code is checked and miss a logic bug by not covering a case in your unit tests. You are writing unit tests, right?

Re: Zig's New Relationship with LLVM

#126

Post by wyldfire » Mon, Sep 28, 2020, 3:24 PM UTC

In the video, Kelley refers to Tracy [1]. I hadn't heard of it before but it looks interesting.

[1] https://github.com/wolfpld/tracy

Re: Zig's New Relationship with LLVM

#127

Post by dnautics » Mon, Sep 28, 2020, 3:27 PM UTC

gameswithgo wrote: post #16

IshKebab wrote: post #2

This looks amazing, as do many of Zig's features (e.g. comptime). It's hard to go back to memory errors after Rust, but I hope Zig becomes popular enough with some people (those that don't care about security? maybe game developers?) that it influences future languages.

Zig has a lot of features that make it really nice for game development. Easy and no overhead C interop of course, good runtime performance, fast compilation. While it doesn't have as much safety as Rust it is at least a half step between C and Rust, with option types and better management of undefined behavior. Zig probably makes more sense as a gamedev language than Rust for single player/non networked games, where…

Safety is a much more complicated topic than "does my language guard against memory safety", so I wouldn't slyly dismiss zig as "only good for games".

Re: Zig's New Relationship with LLVM

#128

Post by reader_mode » Mon, Sep 28, 2020, 3:29 PM UTC

higerordermap wrote: post #77

simias wrote: post #49

Earlier quoted context omitted.

Can you explain what you have in mind exactly? I'm very much a system programmer and very much not a webdev and I'm basically in love with Rust, so I'm not really sure why you feel that way. I admit that I don't know much about Zig and it does seem like a very interesting language, but at a glance it seems to me like the type system is significantly weaker than Rust's (which may be a good thing for compile times). Fo…

a strong type system in itself doesn't cause slowness in compiler. A large part of time is spent in code generator. Rustc produces lot of LLVM IR and it is mentioned there is some technical debt there. For systems languages I don't think dynamic dispatch instead of monomorphization is not the right way to implement generics. And zig doesn't seem to be doing dynamic dispatch either. It shouldn't affect the amount of c…

> or map-filter chains instead of for loops.

Not a rust programmer - but this seems odd. Map/filter/reduce are high level abstractions that describe most common operations you want to perform on sequence. It's non-trivial to infer from loop code (you need to scan at least multiple lines to confirm it's actually "just a map" or "just a filter", especially when you have more complex operation chains etc. and the mutable imperative nature of the code makes it even harder to reason about - more potential edge cases).

This is exactly the kind of stuff I don't want to do manually and expect the compiler to do at (near) zero cost - how can you "overuse" this ?

Re: Zig's New Relationship with LLVM

#129

Post by schaefer » Mon, Sep 28, 2020, 3:29 PM UTC

Wow, that profiler that he’s using looks slick! Definitely going to check it out!

Re: Zig's New Relationship with LLVM

#130

Post by benesch » Mon, Sep 28, 2020, 3:30 PM UTC

evmar wrote: post #119

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…

At one point I got Chrome (a genuinely massive C++ project) to compile+link in under six seconds: http://neugierig.org/software/chromium/notes/2011/02/ninja.h... One of the big tricks not mentioned there is to decompose the app into multiple .so files (only when debugging -- release is still a single binary), so that you don't need to rebuild files unaffected by your incremental changes. I wrote more about that here:…

Oh, wow, I didn't realize that incremental compiles for Chromium were what had inspired you to write Ninja! I'm a huge fan of Ninja.

Composing a project of multiple shared libraries is a trick I've wanted to employ many times. Unfortunately neither Rust nor Go—the languages in which the two largest software projects I've worked on professionally are written—supports that model. (At least, not without throwing away the language-default build system, which has a lot of other costs.)