Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig: Build System Reworked

ziglang.org

Post reply on HN
Print view View original

201–210 of 263 posts

Re: Zig: Build System Reworked

#201

Post by trueno »

ACCount37 wrote: post #13
portly wrote: post #8

After having used Zig for a couple of months now I am convinced it is a fantastic tool language. You just pick it up to hack some idea together freely. Every time I hit a wall, I find the creators have thought of it already and offers comfort. But nothing gets in your face how to use the programming language "correctly". For me it is now the go-to "tinker in my garage" language.

Is it really that good? My go-to "tinker in my garage" language is Python - lightweight syntax that stays out of your face, batteries included, packages for everything that's not included. What's Zig's edge?

took me a minute but once i started tinkering with compiled outputs and not dealing with runtimes and venvs my ability to tinker went super crazy. being able to pass something off to my vps with no dependencies if i was tinkering with something hosted was fantastic, or sharing a sidequest with a coworker that's buttoned up and ready to go with no additional environment setup for them

Re: Zig: Build System Reworked

#202

Post by lukaslalinsky »

dnautics wrote: post #154
nullpoint420 wrote: post #144

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)

It's not just I/O, it's also mutexes, condition variables, time, etc. It's not horrible, but it does add up, so calling it super efficient is a stretch.

Re: Zig: Build System Reworked

#203

Post by kristoff_it »

tarruda wrote: post #198
kristoff_it wrote: post #180

Earlier quoted context omitted.

> If so, does that mean that every function in zig is a stackless coroutine? No and yes. If you're using Io.Threaded, then the concurrency model is multithreading and calling Future.await will block your thread on a OS futex. If you're using Io.Evented, then the concurrency model is green threads / fibers and calling Future.await will suspend the current green thread by yielding (swapping CPU state with another fiber…

> there's an accepted proposal to bring them back, in which case any function that calls await, or that otherwise has a suspension point, would have to be transformed into a stackless coroutine by the compiler, yes. The plan is for that to happen transparently without requiring an `async` annotation in the function signature, like we already did in the past. If the compiler will treat functions that call a library fu…

It's not Future.await that is special per se, it's that it (Future.await) will have in it somewhere either in its body or in another function that it calls in turn, a use of `suspend` (using old Zig syntax).

`suspend` is the keyword that best fits your description (you can think of it as being closely related to `yield` in other languages), and it's kind of a lower-level primitive compared to async/await.

This also means that, according to our plans, Zig will have to propagate "stackless-ness" upwards in the call chain while analyzing the code (thus making Future.await not special per-se).

Re: Zig: Build System Reworked

#204

Post by chaz72 »

kristoff_it wrote: post #156
chaz72 wrote: post #90

Earlier quoted context omitted.

My guess is that one of these (Andrew) is measuring syscalls and the other is measuring vtable indirections.

A vtable indirection is essentially free when you're going to perform a syscall. What matters is that the buffer is above the vtable (which is already the case for the current implementation) so that you don't pay for the indirection when hitting the buffer.

Apples and oranges, yeah. I should have spelled that out more, thanks.

Re: Zig: Build System Reworked

#205

Post by Zakis1 »

insanitybit wrote: post #183
sourcegrift wrote: post #96

Would someone tell a rust user why they should and should not try zig?

> and should not try zig? Because it isn't memory safe. I honestly think it's beyond the point of "irresponsible" and well into "negligence" that we're still developing unsafe technologies - people are being harmed by this choice. It's one thing when you have to target specific platforms and maybe Rust wasn't an option or whatever, but the reasons to choose unsafe languages at this point are vanishingly small. Zig is…

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?

Re: Zig: Build System Reworked

#206

Post by tarruda »

kristoff_it wrote: post #203
tarruda wrote: post #198

Earlier quoted context omitted.

> there's an accepted proposal to bring them back, in which case any function that calls await, or that otherwise has a suspension point, would have to be transformed into a stackless coroutine by the compiler, yes. The plan is for that to happen transparently without requiring an `async` annotation in the function signature, like we already did in the past. If the compiler will treat functions that call a library fu…

It's not Future.await that is special per se, it's that it (Future.await) will have in it somewhere either in its body or in another function that it calls in turn, a use of `suspend` (using old Zig syntax). `suspend` is the keyword that best fits your description (you can think of it as being closely related to `yield` in other languages), and it's kind of a lower-level primitive compared to async/await. This also m…

> This also means that, according to our plans, Zig will have to propagate "stackless-ness" upwards in the call chain while analyzing the code (thus making Future.await not special per-se).

Very interesting, will be following Zig development more closely. Thanks for sharing!

Re: Zig: Build System Reworked

#207

Post by SvenL »

childintime wrote: post #163
Decabytes wrote: post #149

There is an idea I've been kicking around for a long time, which I'll just call dual programming. The idea is to develop a stack that consists of just two programming languages, 1 higher level language, and one lower level language. You are supposed to do as much programming as you can in the high level language, and only drop into the low level language as needed. The problem is that unless you already know a low le…

C# is close to achieving that goal.

People always laugh when I mention C# in this regard. It has so many things, like pointer, you can define that memory alignment works like in C, SIMD, AoT compilation, Span. I think you can do pretty much C like programming in C#.

Re: Zig: Build System Reworked

#208

Post by IshKebab »

justinhj wrote: post #168
IshKebab wrote: post #160

Earlier quoted context omitted.

Tbh I don't know enough Zig to answer that. Can you give an example? E.g. some non-performance-sensitive function that returns a string? In Rust and C++ you can treat the string exactly the same as you would an integer and it's super easy. In C you have pain. Does the caller allocate a buffer? How does it know how big to make it? Do you have to have separate calls to calculate the required length? Etc. Can Zig work l…

An arena allocator lets you treat a series of allocations as a single block. In cases where you find yourself needing to micromanage a bunch of small memory allocations you can simply ignore freeing them individually and free the whole arena when you are done.

Yeah sorry I know what an arena allocator is. I meant how can you write code that deals with strings (joining, formatting, passing around etc.) but isn't sensitive to performance (so `std::string`-like performance is fine) in Zig without having to deal with tedious low level allocator details. If I have to pass an allocator around everywhere that's a pain in the bum.

Apparently Zig doesn't have a global allocator so it seems like you can't. (And it seems like the allocation details aren't encoded in the type anyway so it will be a disaster if you start mixing up global and non-global allocator types anyway.)

Re: Zig: Build System Reworked

#209

Post by lll-o-lll »

ACCount37 wrote: post #13
portly wrote: post #8

After having used Zig for a couple of months now I am convinced it is a fantastic tool language. You just pick it up to hack some idea together freely. Every time I hit a wall, I find the creators have thought of it already and offers comfort. But nothing gets in your face how to use the programming language "correctly". For me it is now the go-to "tinker in my garage" language.

Is it really that good? My go-to "tinker in my garage" language is Python - lightweight syntax that stays out of your face, batteries included, packages for everything that's not included. What's Zig's edge?

“Tinker in my garage” for low level things. If I’m playing around with a custom layer 2 protocol, python is not my language of choice.

Basically, if what you are tinkering needs precise control over the bits and bytes, Zig (or C) are designed for it.

Re: Zig: Build System Reworked

#210

Post by OtomotO »

ACCount37 wrote: post #13
portly wrote: post #8

After having used Zig for a couple of months now I am convinced it is a fantastic tool language. You just pick it up to hack some idea together freely. Every time I hit a wall, I find the creators have thought of it already and offers comfort. But nothing gets in your face how to use the programming language "correctly". For me it is now the go-to "tinker in my garage" language.

Is it really that good? My go-to "tinker in my garage" language is Python - lightweight syntax that stays out of your face, batteries included, packages for everything that's not included. What's Zig's edge?

That's so funny.

At university we didn't use Python, but mostly Java, C++, C a bit of Haskell and some even more esoteric ones.

Sure thing I got exposed to Python, but to this day, I don't like it.

All that whitespace typing just kills me xD

I am not normally someone who cares the slightest about Syntax.

I've written Rust, C++, C, C#, JavaScript, TypeScript, Haskell, Kotlin, Scala, PHP, and many, many more in my spare time and being paid to... Yes, I've also been paid to write Python and I use it for some scripts instead of bash occasionally, but boy will I never like Python

Post reply on HN