Live data from Hacker News

Zig's New Relationship with LLVM

kristoff.it

101–110 of 295 posts

Re: Zig's New Relationship with LLVM

#101
post #33

Earlier quoted context omitted.

That's interesting because the people I've seen that are part of the zig foundation all have some sort of web-adjacent background; I know Andrew has mentioned working at OKCupid, and the author of this post worked at Redis. To some degree, this is probably just because that's where the money is (A quick look at Andrew's blog shows lots of non-web stuff for personal projects prior to Zig), but the gravity of a day-job…

Andrew worked at OKC, but I seem to recall their backend being written in C++so he isn't exactly a "traditional" webdev for the late 2010s/2020s.

But it was quite traditional in the 2000's, see ATLServer.

Re: Zig's New Relationship with LLVM

#102
post #73

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…

Ouch, my first foray into Zig several months to a year ago also ended when my compilation of a copy-pasted version of the very first Hello, World code sample failed. (Copy-pasting of the second example did work, but still) Sad to see this hasn't changed in so long. Good documentation, especially for just starting out, is crucial for language uptake.

Zig purposely does not parse carriage returns or tabs. When this is brought up, people tell you to use a separate program to format it before compiling and don't seem to acknowledge that this is not a problem with any other language.

The result is that by default you get errors on windows with hello world programs. People will tell you to just change your defaults in your text editor to not write carriage returns. There seems to be a lot of rationalizations from a very unpragmatic choice.

Re: Zig's New Relationship with LLVM

#103
post #65
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…

I really like the Zig approach of improving the tooling for manual memory management rather than replacing manual memory management. I think Rust is a great, worthy language, and for a lot of use-cases it makes sense to optimize for trying to just put everything on the stack, but there are a lot of other cases where what you really want to do is own allocation by yourself instead of trusting it to the compiler. I hav…

> I really like the Zig approach of improving the tooling for manual memory management rather than replacing manual memory management.

The new test allocator checks your code for memory leaks, use after free, and double free in a highly ergonomic fashion. I think is fantastic that zig encourages writing tests, and I think if you get full test coverage in your zig code with the test allocator, you will probably solve 99% of your memory errors.

I know this is possible in C++ (see alexandrescu's allocators talk from CppCon 2017?) But I would be surprised if anyone does it.

Re: Zig's New Relationship with LLVM

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

Fully agree. There were many other attempts at building a better C, but Zig's big achievement is that it offers enough new and compelling features that sufficiently distinguishes it from C, while still managing to keep the overall complexity very low while still being familiar. That mix of "fresh, yet familiar and simple" sets it apart.

Re: Zig's New Relationship with LLVM

#105
post #58

Earlier quoted context omitted.

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

You are correct, that's still a WIP, but the goal is to have "safe Zig" (i.e. Zig with safety checks on) catch all undefined behaviour modulo explicitly marked unsafe casts (which correspond to unsafe Rust code).

Re: Zig's New Relationship with LLVM

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

Take off every zig take of every ziiig, totally agree with you. Rust and Zig is totally the best examples of things that are happening now. I am sorry for the introduction but everyone who recognize it will. Zig and Rust is where things' at, Python and Go can go, all us old dudes use Perl anyways-

Re: Zig's New Relationship with LLVM

#107
post #74
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…

Where does the extra productivity in Zig come from in your experience? I haven't worked with it, but my understanding is that memory management is manual and explicit, which tends to come with some cognitive overhead. If Zig has a good solution for this I would be curious how it achieves it.

Defer and errdefer help make the memory handling dead easy.

Re: Zig's New Relationship with LLVM

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

> and possibly the first radical breakthrough in low-level programming design in decades

Can you expand what you mean here?

I really like Zig, and there is definitely a big design space to explore in creating a modern low-level language that doesn't come with the complexity of something like Ada/Spark or Rust.

This binary patching + daemonized compiler approach is particularly exciting.

But as a language, I'm not aware of any features that would amount to a "radical breakthrough". As far as I am aware, it is a modernized, low level language, with nice compile time evaluation, async, and some runtime-provided safety guarantees. But nothing that is so novel from a type system / language design point of view.

Happy to be corrected though!

Re: Zig's New Relationship with LLVM

#109
post #79

Earlier quoted context omitted.

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…

Again, it's not about what you are able to do in Rust vs. Zig, it's essentially about the API of the language. Zig's semantics around memory management are imperative: i.e. you are telling the compiler when to allocate and deallocate memory. Rust's are declarative: you tell the compiler how the memory for a given value should be managed, and the compiler interprets these requirements to decide when memory should be allocated or deallocated.

Again, I do not think this a weakness of Rust, and I do not think it should change. In very many cases, the Rust approach is very helpful.

The point is there are also cases where imperative, explicit memory management is desirable.

Re: Zig's New Relationship with LLVM

#110
post #73

Earlier quoted context omitted.

Ouch, my first foray into Zig several months to a year ago also ended when my compilation of a copy-pasted version of the very first Hello, World code sample failed. (Copy-pasting of the second example did work, but still) Sad to see this hasn't changed in so long. Good documentation, especially for just starting out, is crucial for language uptake.

Zig purposely does not parse carriage returns or tabs. When this is brought up, people tell you to use a separate program to format it before compiling and don't seem to acknowledge that this is not a problem with any other language. The result is that by default you get errors on windows with hello world programs. People will tell you to just change your defaults in your text editor to not write carriage returns. Th…

> When this is brought up, people [...] don't seem to acknowledge that this is not a problem with any other language.

This was a deliberate design decision by andrew for all zig pre-1.0 to supress discussions about coding style (use CR, LF, CRLF, LFCR as a line ending? tabs vs. spaces? ...) as it's considered bike shedding

Zig 1.0 won't have this restrictions anymore. More information can be found here:

https://github.com/ziglang/zig/wiki/FAQ#why-does-zig-force-m... https://github.com/ziglang/zig/issues/544

Post reply on HN