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

171–180 of 295 posts

Re: Zig's New Relationship with LLVM

#171

Post by Guvante »

sai_c wrote: post #133
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…

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 was NLL (non-lexical lifetimes) which was designed to help iron out some of the annoying places the compiler couldn't see what you were doing was safe. One of the constraints they gave in implementing it was no changes to existing code that compiled, the way they did it as a non-breaking change was to ensure that the new system only allowed programs to compile that didn't compile before.

It sounds like you aren't interested in Rust for other reasons but wanted to point out that language hears your concerns about breaking changes being the worst.

Re: Zig's New Relationship with LLVM

#172

Post by rictic »

ikskuh wrote: post #12
tom_mellior wrote: post #7

I don't understand the "in-place binary patching" bit. Does it literally mean that the compiler opens the existing binary in a write-but-do-not truncate mode, leaves most bits in place, and only changes others in certain places? Is this expected to be that much faster than writing the whole binary anew? What other benefits is this supposed to have? The article doesn't seem to say. Also, how does this relate to the ob…

Yes, you understood that right. The existing executable file is not written completly anew. And yes, it will be faster. The way Zig does this is by only recompiling and modifying the parts of the executable where the source has changed. Imagine a project like chromium, where your executable is 150 MB large. Now you change a single function. Classic linking would require the whole linking process and the write of 150…

What if the machine code for the function is larger after than before?

I guess even worst case, writing 151MB to disk is fast if you have the data ready. Very fast with a modern SSD.

Re: Zig's New Relationship with LLVM

#173

Post by pron »

tayistay wrote: post #163
pron wrote: post #141

Earlier quoted context omitted.

Your conclusion rests on the assumption that Rust's sound guarantees are free and have no cost to correctness while they might very well do, or, put differently, that "all else is equal." It's like concluding that you must be richer than me because you have more cash in your wallet. See my comment here for more: https://news.ycombinator.com/item?id=24617127

Yes, I am assuming that Rust isn't much harder to code in than Zig. Rust isn't that hard, really. Since your point doesn't really have to do with which languages are involved (only that they are different somehow), one could similarly say that C might produce more correct programs than Rust or Zig for the same amount of effort. New languages like Zig need to have a better story around safety than "only empirical obse…

> Yes, I am assuming that Rust isn't much harder to code in than Zig. Rust isn't that hard, really.

You're assuming much more. The costs I mentioned are not about being harder to code. C++ is also easy to code in.

> one could similarly say that C might produce more correct programs than Rust or Zig for the same amount of effort.

True, and right now it might very well be. C has exceptional verification tools, which is why a lot of safety-critical software is not written in either C++ or Rust, but in C, Ada, and some domain-specific languages that compile to C like SCADE. But assuming "all external tools being equal" I would guess both Rust and Zig would be better, because they both have a very strong focus on correctness and do something about it, while C doesn't even try.

> because Rust's safety story is pretty compelling.

Zig has an exceptionally compelling safety story as well. It focuses on safety no less than Rust, but it does so in a different way. My personal guess would be that Zig's approach to correctness is at least as good as Rust if not more so, though I could be wrong, and I have no problem with people guessing the other way. After spending years with formal verification and following software correctness research, my only conclusion is that we don't have anywhere near a good model for software correctness that would allow us to make any reasonable projection about approaches.

The story, though, isn't just about correctness, and languages can be compelling in other ways, too. Language preference is largely based on personal aesthetics, and aesthetically Zig and Rust are very different. Rust's aesthetics are not to my liking but Zig's are, just as I'm sure the opposite is true for others. I see no reason why there should only be one aesthetic approach in low-level programming just as there isn't one approach in high-level programming.

So not expecting any resolution on the correctness approach any time yet, I think those two languages would appeal to different people.

Re: Zig's New Relationship with LLVM

#174

Post by wtetzner »

dilap wrote: post #86
danhor wrote: post #53

Earlier quoted context omitted.

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

> So e.g. in Go an unused import is an error.

Which is an incredibly annoying thing, because you can't easily just comment out some code and do a quick build to test something. You are forced to cleanup imports/unused variables every time you want to build something.

Re: Zig's New Relationship with LLVM

#175

Post by Ar-Curunir »

sai_c wrote: post #133
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…

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:…

> "Focus on debugging your application rather than debugging your programming language knowledge." > > I have yet so see a community driven language that fulfills this promise in a comparable way to C's.

I mean, this is only true if you ignore the myriad ways in which C allows you to manifest memory unsafety and undefined behaviour

Re: Zig's New Relationship with LLVM

#176

Post by jiofih »

kristoff_it wrote: post #42
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 think most people actively involved in the community are compiling Zig from master branch or downloading the nightly builds. Zig releases are tied to LLVM so there's usually 6 months between releases, which is way too much time to stay without new features, given the speed of improvement of the language. I think yours is a fair point, but that's how things are. If you prefer using a tagged version and not have to b…

The site specifically instructs you to visit the releases page which only offers 0.6.0

Re: Zig's New Relationship with LLVM

#177

Post by disown »

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…

> Zig shows a third way by rethinking, from the ground up, how low-level programming could and should be done.

I don't know about that. "that of C's "syntax-sugared Assembly" is pretty much how most people want to do system programming. Don't systems programmers want to be as close to assembly without delving into the pain that is assembly? Also, I don't know how "ground up" it is. Seems like zig is just more syntactic sugar on top of C to me.

Wasn't there a big push for D to supplant C/C++ a while back. Now Rust has joined the fray. Why would Zig succeed when D failed and Rust is failing? What is it that Zig offers that D or Rust doesn't? And does that justify the migration of legions of C programmers and mountains of C code to Zig?

Re: Zig's New Relationship with LLVM

#178

Post by the_duke »

ikskuh wrote: post #38
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 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…

> No hidden control flow

It's true that a macro in Rust could introduce an early, invisible return. But this can only happen inside a macro. A reasonable option would be to disallow those in a project where such concerns are critical.

Otherwise Zigs "try" is similar to `?` in Rust, and "defer" comes pretty close to non-obvious control flow for me.

I'm particularly not a big fan of "defer" (and "errdefer"), which I already don't like in Go. Sprinkle multiple of those in a larger function, and following the logic can become quite tedious.

Re: Zig's New Relationship with LLVM

#179

Post by dilap »

wtetzner wrote: post #174
dilap wrote: post #86

Earlier quoted context omitted.

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.

> So e.g. in Go an unused import is an error. Which is an incredibly annoying thing, because you can't easily just comment out some code and do a quick build to test something. You are forced to cleanup imports/unused variables every time you want to build something.

Tradeoffs :-)

(Also, if you use something like goimports, it's pretty much automatic.)

Re: Zig's New Relationship with LLVM

#180

Post by alexnask »

jiofih wrote: post #176
kristoff_it wrote: post #42

Earlier quoted context omitted.

I think most people actively involved in the community are compiling Zig from master branch or downloading the nightly builds. Zig releases are tied to LLVM so there's usually 6 months between releases, which is way too much time to stay without new features, given the speed of improvement of the language. I think yours is a fair point, but that's how things are. If you prefer using a tagged version and not have to b…

The site specifically instructs you to visit the releases page which only offers 0.6.0

This is just not true, the master build is literally the first thing you see on the download page.

Don't get me wrong, it should be clarified on the ziglearn website anyway.

Post reply on HN