Zig's New Relationship with LLVM • Hacker News Board

Re: Zig's New Relationship with LLVM

#91

Post by nyanpasu64 » Mon, Sep 28, 2020, 2:44 PM UTC

skohan wrote: post #71

higerordermap wrote: post #56

Earlier quoted context omitted.

I don't think zig is very well suited for / should target web dev. There a GC'd language with modern features should do best. Imagine OCaml but modern and great tooling. That would be easy for developers, more productive to write, less type errors, also more productive because of IDE support, and much faster than current crop of scripting languages. Sadly, there is a vacuum for such a language. Go is too gruntwork an…

> There a GC'd language with modern features should do best. I predict that there will be a paradigm shift away from GC in the next round of languages. I suspect what will win for something like web-dev will be a language with static memory management like Rust, but at a higher level, with slightly more tolerance for abstractions of non-zero cost.

https://boats.gitlab.io/blog/post/notes-on-a-smaller-rust/ might be inspiration for such a language.

Re: Zig's New Relationship with LLVM

#92

Post by Ar-Curunir » Mon, Sep 28, 2020, 2:45 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…

Rust was developed for a core systems programming task: writing a browser. Yes, there is lots of influence from PL research, but I fail to see how the community is FP oriented.

Re your points about toolchain: Rust is also developing a non-LLVM backend, and is one of the better compilers for incremental compilation

Re: Zig's New Relationship with LLVM

#93

Post by tom_mellior » Mon, Sep 28, 2020, 2:45 PM UTC

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…

> Now you change a single function. Classic linking would require the whole linking process and the write of 150 MB of code. Zig will only compile and patch a single function (when lucky: less than 1kB) and emit this.

I see, thanks. I think I was misled by the article's "the final executable depends on everything else and so any meaningful change to the code will invalidate it". My understanding now is that, since the Zig compiler knows exactly what has changed, unlike a traditional linker it will not invalidate the parts that haven't changed. Is that correct?

Re: Zig's New Relationship with LLVM

#94

Post by the_duke » Mon, Sep 28, 2020, 2:47 PM UTC

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.

In Zig, as far as I understand, you really just pass an allocator around. I don't see any special syntax to support this?

This could be done in Rust. There is, for example, the simple bump allocator bumpalo [1].

It would be nice if the the std collections supported this (in planning, but hasn't seen much progress), and most dependencies would not be built around a manually passed allocator.

> Rust assumes most of the time you'll be passing around references to values or small structures allocated on the stack.

Can you clarify what you mean here? All of the std collections (Vec, HashMap, etc) use allocation. There are also `Box`, `Rc` and `Arc`, which allocate and are used everywhere.

[1] https://github.com/fitzgen/bumpalo

Re: Zig's New Relationship with LLVM

#95

Post by pjmlp » Mon, Sep 28, 2020, 2:47 PM UTC

sam0x17 wrote: post #39

viraptor wrote: post #28

Earlier quoted context omitted.

> that can achieve exactly the same thing That's a bold claim. What's the C formal validator which automatically handles both memory management and concurrency in source of any size within seconds/minutes? (Without making the source its own dialect rather than C)

True, I'm familiar with ones in Java but not in C/C++. Having written a leak / double free detector for C, I have to say, you can only do so much statically and that wouldn't give me peace of mind exactly.

Frama-C and Microsoft's Security Description Language.

Re: Zig's New Relationship with LLVM

#96

Post by Ar-Curunir » Mon, Sep 28, 2020, 2:48 PM UTC

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

Working on a browser is not “web dev”, at least wrt how “web dev” is defined by many parts of the software community.

(Web dev is a totally cool and difficult engineering thing to do, it’s just disjoint from browser dev)

Anyway, Rust design is no longer influenced in any significant way by Servo, and most Rust contributors are not Mozillians

Re: Zig's New Relationship with LLVM

#97

Post by skohan » Mon, Sep 28, 2020, 2:48 PM UTC

nyanpasu64 wrote: post #91

skohan wrote: post #71

Earlier quoted context omitted.

> There a GC'd language with modern features should do best. I predict that there will be a paradigm shift away from GC in the next round of languages. I suspect what will win for something like web-dev will be a language with static memory management like Rust, but at a higher level, with slightly more tolerance for abstractions of non-zero cost.

https://boats.gitlab.io/blog/post/notes-on-a-smaller-rust/ might be inspiration for such a language.

Aside from the notes on concurrency in this article, the author could easily be describing Swift

Re: Zig's New Relationship with LLVM

#98

Post by nyanpasu64 » Mon, Sep 28, 2020, 2:49 PM UTC

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…

Not a Zig user, but this seems to indicate Zig still doesn't always detect use-after-free even with all safety flags on. It seems progress is being made though. https://github.com/ziglang/zig/issues/3180

Re: Zig's New Relationship with LLVM

#99

Post by pjmlp » Mon, Sep 28, 2020, 2:49 PM UTC

skohan wrote: post #71

higerordermap wrote: post #56

Earlier quoted context omitted.

I don't think zig is very well suited for / should target web dev. There a GC'd language with modern features should do best. Imagine OCaml but modern and great tooling. That would be easy for developers, more productive to write, less type errors, also more productive because of IDE support, and much faster than current crop of scripting languages. Sadly, there is a vacuum for such a language. Go is too gruntwork an…

> There a GC'd language with modern features should do best. I predict that there will be a paradigm shift away from GC in the next round of languages. I suspect what will win for something like web-dev will be a language with static memory management like Rust, but at a higher level, with slightly more tolerance for abstractions of non-zero cost.

I predict that GC languages will prevail and adopt affine types for advanced users to code application hot paths, like D, Swift, Chapel among others are pursuing.

Re: Zig's New Relationship with LLVM

#100

Post by benesch » Mon, Sep 28, 2020, 2:50 PM UTC

_urga wrote: post #90

benesch wrote: post #59

Earlier quoted context omitted.

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.

I wouldn't expect that to matter much during the debug cycle. The whole binary is going to be sitting in the buffer cache.