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.
Zig's New Relationship with LLVM
211–220 of 295 posts
Re: Zig's New Relationship with LLVM
#212Earlier 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…
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
#213Earlier 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.
Re: Zig's New Relationship with LLVM
#214I 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…
Check out that 5 min demo video! I think it's pretty exciting.
Re: Zig's New Relationship with LLVM
#215When 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.
Re: Zig's New Relationship with LLVM
#216Earlier 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.
(To be clear, I don't use Zig, yet.)
Re: Zig's New Relationship with LLVM
#217Earlier 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)
Re: Zig's New Relationship with LLVM
#218In 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
#219Earlier 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…
https://www.drdobbs.com/learning-standard-c-as-a-new-languag...
Re: Zig's New Relationship with LLVM
#220Earlier 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.
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.