Zig – SPIR-V Backend Progress
ziglang.org
Zig – SPIR-V Backend Progress
1–10 of 75 posts
Re: Zig – SPIR-V Backend Progress
#2Really cool to see work progressing on this! It would be awesome to one day be able to use Zig for serious shader work
Re: Zig – SPIR-V Backend Progress
#3I really love everything about zig except the language itself. The governance, the culture, all of it seem really cool, but reading https://ziglang.org/learn/why_zig_rust_d_cpp/ I still don't get _why_ I would use it. To an untrained eye, it seems like go, but with manual allocation. Or an imperative-only rust. Like it has some features of all the languages it competes with, but not the ones that would make me reach for them.
What do people use zig for, and why zig and not one of the others?
Re: Zig – SPIR-V Backend Progress
#4I really love everything about zig except the language itself. The governance, the culture, all of it seem really cool, but reading https://ziglang.org/learn/why_zig_rust_d_cpp/ I still don't get _why_ I would use it. To an untrained eye, it seems like go, but with manual allocation. Or an imperative-only rust. Like it has some features of all the languages it competes with, but not the ones that would make me reach…
Try reading zig code. For me its much more readable than the other languages, and does not suffer the fact go doesnt have language level errors. Local allocators are very useful and if you dont think so, perhaps you havent dwelved too deeply into systems programming or the language isnt targeted for you.
Re: Zig – SPIR-V Backend Progress
#5I really love everything about zig except the language itself. The governance, the culture, all of it seem really cool, but reading https://ziglang.org/learn/why_zig_rust_d_cpp/ I still don't get _why_ I would use it. To an untrained eye, it seems like go, but with manual allocation. Or an imperative-only rust. Like it has some features of all the languages it competes with, but not the ones that would make me reach…
Try reading zig code. For me its much more readable than the other languages, and does not suffer the fact go doesnt have language level errors. Local allocators are very useful and if you dont think so, perhaps you havent dwelved too deeply into systems programming or the language isnt targeted for you.
I get the usefulness of allocators, I just don't see them as useful enough where I'd pick zig over another established systems programming language. Do you have an example?
Re: Zig – SPIR-V Backend Progress
#6Earlier quoted context omitted.
Try reading zig code. For me its much more readable than the other languages, and does not suffer the fact go doesnt have language level errors. Local allocators are very useful and if you dont think so, perhaps you havent dwelved too deeply into systems programming or the language isnt targeted for you.
I get the usefulness of allocators, I just don't see them as useful enough where I'd pick zig over another established systems programming language. Do you have an example?
I think Zig would do better than Go at things like kernels, drivers, game engines, lower level sorts of things. Edited to add the obvious: SPIR-V, for instance.
Of course there’s lots of programming that can afford to pay for GC side effects, if there weren’t we wouldn’t have invented GC, but it’s a little less universal, a little less ‘system’.
For me, I came to Zig after horrible cross-platform experiences led me to try going all the way back to C and I found that I was spending way too much time learning to deal with accidental complexity instead of essential complexity. (Respect to the C masters but I failed to adapt.)
Re: Zig – SPIR-V Backend Progress
#7Earlier quoted context omitted.
Try reading zig code. For me its much more readable than the other languages, and does not suffer the fact go doesnt have language level errors. Local allocators are very useful and if you dont think so, perhaps you havent dwelved too deeply into systems programming or the language isnt targeted for you.
I get the usefulness of allocators, I just don't see them as useful enough where I'd pick zig over another established systems programming language. Do you have an example?
a lot of heavy duty systems have multiple allocator systems. the erlang virtual machine has 12:
https://www.erlang.org/docs/25/man/erts_alloc.html
jvm has at least 5:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share...
postgres has at least 8:
https://github.com/postgres/postgres/blob/master/src/backend...
since zig anoints an allocator interface in its stdlib, your (and the stdlib's) data structures which use allocators can be trivially reused across different allocation strategies without rewriting code; and very likely (not guaranteed ofc) if you bring in someone else's code they will cleave to convention.
Re: Zig – SPIR-V Backend Progress
#8I really love everything about zig except the language itself. The governance, the culture, all of it seem really cool, but reading https://ziglang.org/learn/why_zig_rust_d_cpp/ I still don't get _why_ I would use it. To an untrained eye, it seems like go, but with manual allocation. Or an imperative-only rust. Like it has some features of all the languages it competes with, but not the ones that would make me reach…
> why zig and not one of the others?
I think one of the selling points is that the language does not come to your way and allows unsafe constructs. So, I think the target audience is roughly at C and C++ users.
Re: Zig – SPIR-V Backend Progress
#9Earlier quoted context omitted.
I get the usefulness of allocators, I just don't see them as useful enough where I'd pick zig over another established systems programming language. Do you have an example?
a lot of heavy duty systems have multiple allocator systems. the erlang virtual machine has 12: https://www.erlang.org/docs/25/man/erts_alloc.html jvm has at least 5: https://github.com/openjdk/jdk/blob/master/src/hotspot/share... postgres has at least 8: https://github.com/postgres/postgres/blob/master/src/backend... since zig anoints an allocator interface in its stdlib, your (and the stdlib's) data structures whic…
Just yesterday I was thinking about the BEAM and would it be tidier if it were written in Zig.
Re: Zig – SPIR-V Backend Progress
#10Side question as I am following zig only losely and do Go Programming:
Zig has the feature that you can drop in your allocator from the caller. Now with 0.16 you also "bring your own IO" implementation with you.
And for my understanding this looks like the pattern Go uses with its Context package, where you pass in transitive data, cancellation signals and timers to for example stop an SQL query in server B, since a user canceled a web request in their browser before hitting server A, whilst all elements delegate the Context.
Then yesterday was total unrelated article about NUMA architecture, and I remember somewhere that the creator of Erlang mentioned (Joe Armstrong) that you cannot get around physics and it takes time to call a function between servers, therefore so not try to hide the latency between the calls.
And now to my question:
Would that in any way make sense for zig to go even more in this direction, where you pass in your allocator, IO, but now with something similar to Google Go context, but have it even more fine grained?
So that your functions could actually in their interface expose somehow the time in between CPU cores (NUMA) up to the request cancellation as Google go context is used for timeout signals, cancellation signals.
Also probably making time an external dependency as well.
So in essence , every function would be treated as a remote procedure calls, whereas remote would mean: "other cpu", other server/service