Live data from Hacker News

Zig's New Relationship with LLVM

kristoff.it

211–220 of 295 posts

Re: Zig's New Relationship with LLVM

#211

I’ve often wanted to try out Zig at work but the dependency on the latest LLVM meant doing that first. Building LLVM from scratch on our platform takes more resources (including time) than I normally have available (LLDB needs like 6GB of RAM to link?) So, I welcome this news!

Zig releases are available in statically compiled form, no dependencies, no compilation necessary.

Note I mentioned I wanted it for our platform... there is no pre-built Zig for it - despite being BSD based.

Re: Zig's New Relationship with LLVM

#212
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…

That's interesting but I don't know if it helps with the parents concern. If I arrive into a project, the same reasons that made them choose rust mean that they have likely chosen the latest version of rust, with all its complexity and power.

If I am inspecting code for safety that is doing low level things then I want to have a clear and simple (imperative) model in my head. I don't want to spend the review admiring how clever the author is. I want to know as directly as possible what is going on in the machine.

In another domain the ability for the author to do clever things could make me very productive but it doesn't matter because the safety of low level code is not a concern.

Re: Zig's New Relationship with LLVM

#213
post #172
post #12

Earlier quoted context omitted.

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.

This is a fascinating topic that I hope to follow up with a more technical blog post. The short summary is that there is room for functions to grow, and if they still exceed the padding, they get moved around to a new location in both virtual memory and in the file. Because of indirect function calls this means callsites remain the same; only the GOT entry has to get updated. The actual function body is moved with the copy_file_range syscall, where available.

Re: Zig's New Relationship with LLVM

#214

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…

> Does linking somehow get faster or easier with in-place patching?

Check out that 5 min demo video! I think it's pretty exciting.

Re: Zig's New Relationship with LLVM

#215

When zig can handle line endings from this century, maybe. It's kinda crazy there's software that bothers the user to restrict CRLF. I tried zig and this was the first issue. I thought I needed to go find my AOL discs or something.

What do you mean? I've used zig on both linux and windows and never had line ending issues.

Re: Zig's New Relationship with LLVM

#216
post #138

Earlier quoted context omitted.

> I'm not sure I like the "better C" label. I agree that Zig is more than a "better C", and I edited my comment. Regarding `comptime`: I haven't fully grokked it, but it looks very similar to the capabilities of D (and in part Nim). Do you by chance know those languages and can give a comparison? (Languages like Idris also allow to express a lot at compile time, but that's quite a different domain)

Nim and D have a similar feature, but Zig's radical design is not in including this feature but in not including others it can replace (generics and macros). Both D and Nim have generics as a separate features, and Nim has macros and D has conditional compilation as a separate features. Zig is not special in having comptime; it's special in having only comptime as the single partial-evaluation mechanism.

Are you sure that minimalism is a design principle of Zig's, and not just the current state of the project? @andrewrk's comments at https://github.com/ziglang/zig/issues/130 lead me to believe that it's still undecided.

(To be clear, I don't use Zig, yet.)

Re: Zig's New Relationship with LLVM

#217
post #116

Earlier quoted context omitted.

> creating a better C I'm not sure I like the "better C" label. After all, Zig allows you to easily do stuff that's virtually impossible in C, and only possible in C++ with templates and constexprs and concepts. It also doesn't have pointer arithmetic and pervasive wild casts, so it's not a "syntax-sugared Assembly". Its only similarity to C is that it is a low-level language and that, unlike other low-level language…

> I'm not sure I like the "better C" label. I agree that Zig is more than a "better C", and I edited my comment. Regarding `comptime`: I haven't fully grokked it, but it looks very similar to the capabilities of D (and in part Nim). Do you by chance know those languages and can give a comparison? (Languages like Idris also allow to express a lot at compile time, but that's quite a different domain)

[deleted]

Re: Zig's New Relationship with LLVM

#218

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

I love Tracy, highly recommend it, and it's another great project worth sponsoring: https://github.com/sponsors/wolfpld

Re: Zig's New Relationship with LLVM

#219

Earlier quoted context omitted.

Similarly, I rolled back to the official docs from Master and the hello.zig from there is similarly nonop using the tagged 0.6.0 build: https://ziglang.org/documentation/master/ Please, please - make a Hello, World which is not so intrinsically tied to random features on Master to just work across all the iterations. Hello, World is supposed to be the simplest, non-breaking easy to compile no esoteric compiler featur…

Use std.debug.warn and you'll be fine with 0.6.0 and master. Right now there's no strict and methodical update path from one version to the next, but generally speaking changes to the language get special-cased into zig fmt. For example the current `anytype` type has replaced `var` and running zig fmt on a project I hadn't updated yet changed all references. That said, Hello World, when taken seriously, it's not that…

Reminds me of Bjarne Strostrup's old article on learning c++ as a new language - and how a simple program in c isn't that much simpler when you start to poke at the details:

https://www.drdobbs.com/learning-standard-c-as-a-new-languag...

https://stroustrup.com/new_learning.pdf

Re: Zig's New Relationship with LLVM

#220
post #168

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.

Sure but a language where "the only hard part" isn't a factor surely has a leg up on one where it is.

A lot of the advantage which Zig has over C is exactly in not having to support a towering edifice of tools and hacks which is older than I am. This is true to a significant degree of Rust and C++ as well.

Post reply on HN