Live data from Hacker News

Zig: Build System Reworked

ziglang.org

231–240 of 263 posts

Re: Zig: Build System Reworked

#231

Earlier quoted context omitted.

Wow that’s gnarly it’s using dynamic dispatch. I mean I get it, but I thought zig was some sort of performance demon.

if youre doing io, one pointer indirection seems unlikely tp be rate limiting. same for allocation (the other dynamic dispatch in zig)

A modern allocator with per-thread cache can satisfy some allocations in 20-30 cycles - dynamic dispatch can easily double that, even if the target is still in cache.

It's one of these things where it's extremely use case dependant - like many performance issues, you probably don't care about it - but when you do it matters.

Re: Zig: Build System Reworked

#232
post #225
post #103

Earlier quoted context omitted.

I doubt Go has any sizable effect on the community of programming language developers. Probably Pascal has more impact on this.

Then you haven't been paying attention to the space. At all. Every single new post-Go language, like Rust & Zig, ships with an opinionated autoformatter and a single go-to command to manage builds, packaging, etc. And how many new languages do you see include inheritance and exceptions? Older languages have started adapting what they can too: - Python with `uv` and `black` - Java with goroutine-like fibers and modern…

Go has exceptions, bad ones at that.

From type theory exceptions are effects, and result types are a form of effects.

Auto formatting has been a thing in IDEs for a decade, and doing pre-commit hooks on CVS with indent was a thing in the 1990's.

Java and .NET had http servers.

Co-routines trace back to languages like Solo Pascal.

Configuration free GC not really that great, given the rewrites into Rust.

Anyway, Oberon, Modula-3, Eiffel, .NET,....

Pauseless GC goes back to real time Java from PTC, Aonix, Aicas, and companies like Azul with their custom hardware.

Re: Zig: Build System Reworked

#233
post #185

Earlier quoted context omitted.

> But nothing gets in your face how to use the programming language "correctly". It doesnt let you have unused variables and theres no multiline comment support. These are fairly significant productivity issues for me

> It doesnt let you have unused variables Andrew Kelly on that: https://www.youtube.com/watch?v=iqddnwKF8HQ&t=2927s Looks like you might be able to get rid of the error easily with annotations.

Very nice interview. The clarity with which Andrew Kelly speaks is refreshing.

Re: Zig: Build System Reworked

#234
post #185

Earlier quoted context omitted.

> It doesnt let you have unused variables Andrew Kelly on that: https://www.youtube.com/watch?v=iqddnwKF8HQ&t=2927s Looks like you might be able to get rid of the error easily with annotations.

So your ice turns 'let unused = func();' into 'let _ = func();' automatically? Okay but then do I later have to grep for 'let _' to find all these unused variables and delete them? This is silly and a has consequence of zig not having any system for warnings

Why not ignore unused variables in debug and warn in release mode?

Re: Zig: Build System Reworked

#235

Earlier quoted context omitted.

> RAII is great; I wish they'd use some light (optional) RAII for strings and containers etc. Is it not possible to build a wrapper that does this? It seems like it should be.

It is. I definitely agree that strings in Zig can be tedious, but the upside is that if you need it, you can build a string library that does everything you want it to do, in the way you want. For comparison, while Rust offers a very rich string library, it's also very strict about what you can/cannot do with strings, so if your use case falls outside of that you're out of luck. With Zig, you can pretty easily roll y…

Library interoperability becomes a PITA when everyone builds their own string library. Then you need conversion libraries.

Re: Zig: Build System Reworked

#236
I wanted to try zig, but the language still moves way, way too fast, they break API for every release, so i simply couldbt keep up, while learning the language/debugging the build system/trying to actually implement what i wanted

After watching the Jetbrains interview, I still want to try again but maybe i ll wait till the 1.0 is out

Re: Zig: Build System Reworked

#237
post #205

Earlier quoted context omitted.

I completely agree. Zig has a nicer DX no doubt - no fighting the borrow checker etc. But if you are are writing software for other people they don't care about how nice your developer experience is, they only want the software to work correctly - and how can you guarantee that the software you wrote does what you expect it to do if it's not memory safe?

how does memory safety guarantee that software does what you expect?

It doesn’t fully guarantee that. But it guarantees you don’t have a huge class of bugs. And it makes concurrency a lot easier to reason about.

No system will likely ever guarantee that software does what you expect. That runs into the halting problem, and practically runs into a verbosity problem. But that doesn’t mean systems that give scoped guarantees aren’t amazing for building (and iterating on) reliable software.

Re: Zig: Build System Reworked

#238
post #215

Earlier quoted context omitted.

> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes. Rudeness may be acceptable elsewhere. Not here.

[flagged]

For the price of all this righteousness you could have provided a reference. Some reference. So that curious bystanders like me can learn from the exchange.

Re: Zig: Build System Reworked

#239
post #231

Earlier quoted context omitted.

if youre doing io, one pointer indirection seems unlikely tp be rate limiting. same for allocation (the other dynamic dispatch in zig)

A modern allocator with per-thread cache can satisfy some allocations in 20-30 cycles - dynamic dispatch can easily double that, even if the target is still in cache. It's one of these things where it's extremely use case dependant - like many performance issues, you probably don't care about it - but when you do it matters .

Inderect call cost is a few cycles, if predicted. Now, you can argue, that it may be mispredicted and misprediction would cost about 20-30 cycles. But if it is mispredicted, then you are not calling into allocator often enough. And if you don't hammer it hard, then why do you care about preformance?

Re: Zig: Build System Reworked

#240
post #215

Earlier quoted context omitted.

> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes. Rudeness may be acceptable elsewhere. Not here.

[flagged]

Could you please not sermonize or act like a demanding customer? We don't, and can't ever, see everything that's posted here, and even if we could it's not appropriate for moderators to adjudicate on the correctness of any claim. It’s by cultivating discussions between different people with different perspectives that we illuminate topics here. Obviously you have deep expertise on those topic. Great! Please educate people rather than berating them.

This is only a place anyone wants to participate on because we have guidelines and others make the effort to observe them. You've been here long enough to know that. Please don't trash what you seem to have found value in for so long. We don't need you to be "effusively pleasant" or erudite, just respectful.

Post reply on HN