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

41–50 of 295 posts

Re: Zig's New Relationship with LLVM

#41

Post by smaddox »

johnnycerberus wrote: post #24
sam0x17 wrote: post #17

Earlier quoted context omitted.

If anything, Zig will have much fewer restrictions (no borrow checker) than Rust when it comes to web dev, once Zig matures to the point where there is a good standard HTTP client and server implementation and a package manager. I'm a fan of Rust for things like a missile control system or a stock exchange, but not, say, writing a CRM. I'd gladly write a CRM in Zig however, given the proper library support and toolin…

While I like what Rust is trying to achieve, I would never use something that is not formally proven. There are many, many other static analysis tools in the C and Ada world that can achieve exactly the same thing. They imply less risk, they are way more mature (~40 yo) and have bigger communities around them. Zig is a better C and C++. It should be used accordingly. It will do well in game servers, simulation server…

Rust's borrow checking algorithm has been formally proven for a subset of the full language. Although this is one of those places where intuition is adequate to show the value, i.e. of enforcing exclusive mutability. After all, the intuition and implementation came before the proof (as is often the case).

Re: Zig's New Relationship with LLVM

#42

Post by kristoff_it »

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 be too involved in the latest developments of Zig, please consider waiting until 0.8.0 at the very least.

Re: Zig's New Relationship with LLVM

#43

Post by alexnask »

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…

Hi, I don't necessarily disagree with you, however master builds are available for download for tier 1 targets on zig's website.

The ziglearn website explicitly points to the website for this reason, although I agree it should probably include some warning about using the latest tagged release and how some of the tests will break.

The fact that debug.warn was renamed to debug.print during this release cycle makes this extra unfortunate, since it affects the hello world program.

Anyway, thanks for pointing this out, I will make sure to PR ziglearn to clarify this.

Re: Zig's New Relationship with LLVM

#44

Post by ifreund »

aidenn0 wrote: post #36

With PIC, incremental compilation, and function calls through a GOT, can Zig patch a running binary as well?

You're totally right that at least 90% of the infrastructure is there. Andrew's been threatening to implement hot code swapping in a live stream but has been busy with other tasks it seems.

Re: Zig's New Relationship with LLVM

#45

Post by zokier »

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…

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

Re: Zig's New Relationship with LLVM

#46

Post by nick_ »

kristoff_it wrote: post #14
pedrow wrote: post #10

This is interesting stuff. Could you comment about optimization? LLVM has put a lot of effort into optimizing code at various levels, including the LTO stuff. Will Zig match all this by itself, or will a 'Release mode' still use LLVM to produce a final version?

LLVM is still going to be used for release builds. As of now, the self-hosted backend is dedicated to producing debug builds without optimizations (and with a few extra runtime inefficiencies, as that's the price for faster in-place binary replacement).

Thanks, that's the answer to my question :) Do you know if there has been any plans to implement this build-time optimization upstream in LLVM itself? Perhaps after it's been completed within Zig.

Re: Zig's New Relationship with LLVM

#47

Post by ikskuh »

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…

Note that tagged releases in zig are just "the first state that worked with the new LLVM version".

Imho it would be unreasonable to even try keeping backwards compatibility in a language that tries to find the global maximum

> but geez this is a Hello, World sample that fails This is because the 0.7.0 release cycle changed a lot about logging: std.debug.warn was used as a general purpose log function in 0.6, but is now deprecated to move people to use the std.log namespace now

> It'd be nice if your getting started guide only used features from the tagged latest version at least...

The problem here is that package manager maintainers only package tagged versions which isn't really a good thing for zig. Your version is kinda outdated as soon as you downloaded it. Most projects won't break anymore on a daily basis, but there is still changes, bug fixes and additions.

I'm currently waiting for some PRs to be merged, so i can continue my own projects. You won't get this when sticking to tagged releases (and it will make updating your projects way more painful than keeping them up-to-date on a daily basis)

But yeah, ziglearn could note that using a tagged version has these problems and that zig is moving so fast that sticking to a tagged version will yield outdated code very quickly

Re: Zig's New Relationship with LLVM

#48

Post by kristoff_it »

gravitas wrote: post #40
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…

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 simple of a program and I'm working on a talk for Zig SHOWTIME[1] about it, titled "Advanced Hello World in Zig".

The TLDR is that Zig never had an easy builtin print function because it's important to let the programmer be precise about whether they want locking (or not) or buffering (or not). That's why the easy print function is in the debug namespace.

[1] https://zig.show

Re: Zig's New Relationship with LLVM

#49

Post by simias »

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.

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). For instance I see that they have special syntax for optional types (?) and for error handling (try/catch) when Rust can implement those using basic language constructs (Option and Result). Sure Rust also has the "?" sugar to make error bubbling nicer (like try in Zig) but it's just sugar, it doesn't do anything you can't do with normal Rust code (hence the older try! macro).

More generally I'm not really sold on their implementation of generics. It's the main reason I never gave Go a chance and Zig's version don't seem a whole lot better as far as I can tell. Rust's generics are complex and incur significant compilation overhead but they're also incredibly powerful.

Re: Zig's New Relationship with LLVM

#50

Post by sobeston »

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

Post reply on HN