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

81–90 of 295 posts

Re: Zig's New Relationship with LLVM

#81

Post by benesch »

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…

Were you working on a C/C++ project, out of curiosity? Of the two projects I've meaningfully benchmarked gold on, one was written in Rust and one was written in Go. I can believe that the Rust/Go toolchains make life difficult enough for gold that there is less of a speedup realized.

And yeah, the `--incremental` support in gold is definitely very exciting. Unfortunately it is not complete enough that I've been able to use it on any of the projects where it would matter. Part of what gets me so excited about having first-class support in Zig is that it will work end-to-end, and adjust folks' expectations of how fast linking should be. Then those folks will go demand the same linking speeds of their C/C++/Rust/Go projects.

Building incremental support into LLVM/gcc/gold is definitely the long-term answer, but building an end-to-end incremental toolchain in Zig from scratch to prove the concept makes a ton of sense.

Re: Zig's New Relationship with LLVM

#82

Post by whatshisface »

skohan wrote: post #79
whatshisface wrote: post #70

Earlier quoted context omitted.

Rust has manual allocation with Box , it's just not as automatic as Zig. Rust's manual allocation pain is constant-factor overhead: typing out the type signatures takes longer every time you use it, but the complexity doesn't grow beyond that. I don't enjoy typing Box everywhere, but it's not that bad. https://doc.rust-lang.org/std/boxed/index.html

Rust allows virtually any type of memory management you want, my point is the syntax is not optimized for things like arena-based memory management or custom allocators. Rust assumes most of the time you'll be passing around references to values or small structures allocated on the stack.

Yes, that's quite right. For many purposes, that's helpful encouragement, but sometimes you just want a reference.

Re: Zig's New Relationship with LLVM

#83

Post by [deleted] »

mjtlittle wrote: post #78
oshea64bit wrote: post #31

Earlier quoted context omitted.

Maybe this is an ignorant question, but how exactly is Rust influenced by web dev? I don't see how the aspects that make Rust popular (ownership, lifetimes, strong type system etc.) contribute much to web dev in particular. Languages used for the web like JS, Python, Ruby seem popular precisely because they abstract lower-level details.

Rust is heavily funded and maintained by Mozilla for use in Firefox's engine, Servo

[deleted]

Re: Zig's New Relationship with LLVM

#84

Post by gravitas »

sobeston wrote: post #50
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…

I have done this as zig makes many breaking changes often, not because new features come out all the time (almost all of the things showcased on the site if not all were around back in 0.6). I do not want to teach people things that are already for the most part outdated. Things move very fast, especially in the standard library. edit: to clarify I am the maintainer/owner of ziglearn

nod From my other replies, it would be of assistance to state that this on the guide right at the Install section, as I did have a choice which zig to use and chose the simple package from my repo given no further direction. (BTW: could you explain why I should install ZLS in step 4? Since we're here.. :) )

With a line of text that I must use the latest dev/git code (etc.), my choice would have then gone the other direction to just download a binary. The number of websites which "just download a binary" when a suitable package is already available in the repo are a very high number (for Arch), so this thought process is standard for a guy like me.

Re: Zig's New Relationship with LLVM

#85

Post by IshKebab »

pron wrote: post #58
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 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…

> the goal is not to write your program in a language with some guarantees

How is that not the goal? The more bugs I can statically guarantee are absent the better!

Re: Zig's New Relationship with LLVM

#86

Post by dilap »

danhor wrote: post #53
ikskuh wrote: post #38

Earlier quoted context omitted.

Zig is also designed around safety and security. It's not as obvious as with Rust, but it's still there. Zig is way easier to verify than rust code (no hidden control flow, no hidden allocations that might fail, ...) which means a security expert can read a single function (without knowing more about the code) and can reason about that function. This does not work in languages like C++ and Rust where RAII is a common…

> Zig has no warnings. That sounds very fraught with issues to me. Does that mean existing code will have to be updated in case other behavior turns out to be kinda iffy in practice? Isn't there a strong perverse incentive to just not add anything if that's the case? What about the deprecation of existing code?

Go also has no warnings, and it seems to be working fine.

(Though, some people do use linters to get back the warnings. But the language itself doesn't have any.)

The main thing about having warnings isn't being silent in the face of possibly-shady constructs, it's about just making them errors, so you can be sure they don't occur. So e.g. in Go an unused import is an error.

Re: Zig's New Relationship with LLVM

#87

Post by runevault »

aidenn0 wrote: post #33
higerordermap wrote: post #3

I always like innovations in programming tooling. To me zig sounds like a system language written by system programmers, while rust is more influenced from FP and webdev communities, which is reflected in both tooling and language. To people asking why zig when there's rust, both are nice in different ways.

That's interesting because the people I've seen that are part of the zig foundation all have some sort of web-adjacent background; I know Andrew has mentioned working at OKCupid, and the author of this post worked at Redis. To some degree, this is probably just because that's where the money is (A quick look at Andrew's blog shows lots of non-web stuff for personal projects prior to Zig), but the gravity of a day-job…

Andrew worked at OKC, but I seem to recall their backend being written in C++so he isn't exactly a "traditional" webdev for the late 2010s/2020s.

Re: Zig's New Relationship with LLVM

#88

Post by MaulingMonkey »

benesch wrote: post #81
MaulingMonkey wrote: post #55

Earlier quoted context omitted.

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…

Were you working on a C/C++ project, out of curiosity? Of the two projects I've meaningfully benchmarked gold on, one was written in Rust and one was written in Go. I can believe that the Rust/Go toolchains make life difficult enough for gold that there is less of a speedup realized. And yeah, the `--incremental` support in gold is definitely very exciting. Unfortunately it is not complete enough that I've been able…

> Were you working on a C/C++ project, out of curiosity?

Yes. My numbers are for a somewhat template heavy C++ project. I could see Rust/Go having different performance characteristics on that front.

Re: Zig's New Relationship with LLVM

#89

Post by pron »

IshKebab wrote: post #85
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…

> the goal is not to write your program in a language with some guarantees How is that not the goal? The more bugs I can statically guarantee are absent the better!

> How is that not the goal?

The goal is to produce a program with as few serious bugs as possible, as cheaply as possible. It is never a goal to use a programming language with certain properties; that could just be a means to that end.

> The more bugs I can statically guarantee are absent the better!

Only provided that those guarantees don't come at a cost that could make finding the bugs you don't statically eliminate harder. How could it make it harder? By making the language overall harder to understand -- both by informal and formal analysis -- making safe evolution more tricky, and by slowing down compilation, which slows down the testing cycle and reducing the number of tests you write.

Correctness is a very complex subject, and that "the more sound guarantees the better" is not a consensus opinion on how to get there. For example, even in formal verification circles, a lot of current research focuses on reducing soundness (e.g. concolic testing vs. model-checking/deductive proofs). It's like the question of how to catch more fish: is a smaller net with small holes that guarantees no fish can get through it better, or is it better to cast a wider net with larger holes, that might let some fish slip through but covers a wider area?

Perhaps in the case of the net and the fish an answer could be given ahead of time if you know everything there is to know about the distribution of the fish size and their dispersion, but that's not the case with software bugs. We simply don't know enough, and the only way to answer the question is through empirical observation, over a wide range of applications and over a long time. It's also possible that both approaches are equally good at achieving correctness, and then it's just a matter of personal preference based on other aspects of the language.

Re: Zig's New Relationship with LLVM

#90

Post by _urga »

benesch wrote: post #59
zokier wrote: post #45

Earlier quoted context omitted.

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

That's not a stupid question. That's extremely insightful! That is exactly my model of the world, in fact. When linking incrementally, you don't want a tightly packed object file where the functions are stacked right on top of one another. You want something more akin to a key–value database, where you can swap out key–value pairs without corrupting the entire file. Whether that's an object file that "symlinks" a bun…

I'm with you on the mental model, but from a hardware point of view what you also don't want is hundreds of random disk seeks. I know we're almost in an SSD-only world but HDDs are still a thing and large sequential reads are always important at any level of the memory hierarchy.
Post reply on HN