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

Zig – SPIR-V Backend Progress

ziglang.org

Post reply on HN
Print view View original

51–60 of 75 posts

Re: Zig – SPIR-V Backend Progress

#51

Post by PunchyHamster »

chaz72 wrote: post #6
laszlojamf wrote: post #5

Earlier 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?

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 t…

>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.

But people don't write those in Go, they use Rust for it

Re: Zig – SPIR-V Backend Progress

#52

Post by flohofwoe »

PunchyHamster wrote: post #50

Adding some particular graphics related type as builtin seems a bit weird

I think it's an elegant solution. SPIR-V requires this sort of type annotations, and a builtin like `@SpirvType()` is quite 'Zig idiomatic' and looks to me like the right way to do it since it doesn't "pollute" the language with a dozen new keywords.

In C/C++ and MSL that information would be provided via `[[ ... ]]` attributes (which may look even messier), and other shading languages usually have dedicated keywords (most readable, but it 'pollutes' the entire language for what in Zig would be a niche use case).

Re: Zig – SPIR-V Backend Progress

#53

Post by tremon »

coxmi wrote: post #35
thrwyexecbrain wrote: post #33

Earlier quoted context omitted.

"Dot" in zig is a placeholder for types that can be unambigously inferred from the surrounding expression. So ".unknown" is a standin for "SomeEnum.unknown" or "SomeStruct.unknown", depending on what .format is.

Yeah, after looking it up, it looks like it is basically only used as either field access or an 'infer operator', is that right? I thought it was used in four completely separate ways: · normal struct field access · anonymous struct definition · field definition within structs (for reasons to do with the parser) · an extra 'infer operator' for syntactic sugar But there's no support for anonymous structs/fields, and a…

I don't think that "infer operator" is a special case of field access, to me it feels like regular known-type elision similar to how C# and C++ use the var keyword if the data type can be inferred from the rhs expression:

    const Enum = enum {one, two, five};
    const t: Enum = .one;  // Enum.one, but the type was inferred from lhs
    std.debug.print("{t}\n", .{t});
Defining an anonymous struct is valid in zig; your example is only invalid because "test" is a reserved keyword. But you are correct that it reifies into a concrete type, and after initialization it doesn't coerce into other types because zig doesn't do structural typing:

    const anonymous = .{ .x = 0, .y = 1 };
    std.debug.print("{}\n", .{@TypeOf(anonymous)}); // will output something like test_0__struct_45138

    const Point = struct { x: i32, y: i32 };
    const p1 = Point{ .x = 0, .y = 1 };  // valid, explicit struct literal
    const p2: Point = .{ .x = 0, .y = 1 };  // valid, anonymous struct will coerce to Point
    //const pt: Point = anonymous; // error: expected type 'test_0.Point', found 'test_0__struct_45138'
And then there's fieldless anonymous structs aka tuples. I'm including them because they were used in the print statements above:

    const tuple = .{ 0, "1", true };
    std.debug.print("{}\n", .{@TypeOf(tuple)});
    // struct { comptime comptime_int = 0, comptime *const [1:0]u8 = "1", comptime bool = true }

Re: Zig – SPIR-V Backend Progress

#54

Post by noelwelsh »

epolanski wrote: post #40
noelwelsh wrote: post #39

Earlier quoted context omitted.

You're right, they are related. One difference is simply lineage. Capabilities come out of the erights / security world (e.g. [0]), while dependency injection comes from the XP / agile / Martin Fowler world. More interesting is that to do capabilities correctly you need some type system extensions, namely capture checking. Essentially, this means you delimit where a program can hold a reference to a value derived fro…

So it's essentially low level dependency injection where it's not just about the interface but the system and it's resources too, right? I will take a look at your content, these topics interest me a lot.

That's a reasonable way of looking at it, but capabilities are not restricted to low-level system properties. Here's a terminal UI system built around three main capabilities:

- layout (adding components to the component tree) - event (handling user input events) - react (reacting to changes in reactive values)

https://github.com/creativescala/terminus/tree/main/ui/share...

This is the case study I'm using for the book chapter.

Re: Zig – SPIR-V Backend Progress

#55

Post by dnautics »

auraham wrote: post #17
dnautics wrote: post #15

Earlier quoted context omitted.

> What do people use zig for, and why zig and not one of the others? I'm the maintainer of zigler ( https://zigler.hexdocs.pm/Zig.html ), and I have my own pharma startup. I currently use zig in two contexts: 1) wraps a proprietary .so file that is used to communicate with a scientific (microscope) digital camera, in a nice BEAM-module-shaped interface. Sorry, code is private. 2) I have a vue.js component that does D…

Can you give more details about using zig along with elixir? > microscope is mounted on a elixir nerves deployment! What do you mean? I imagine that there is an Elixir application running on an embedded system and maybe it relies on an external binary application (compiled using zig). If so, how do you manage the communication between them?

no, it mounts a .so file using dlload, and itself is a NIF.

Incidentally there is a second proprietary industrial camera on there that I have running as a different NIF built in zig, but truth be told I probably could have had claude do that one in pure elixir. However, claude did write a harness that I used to inspect the usbpcap dumps (and create the camera interface), that was done in zig for simplicity and turning it into a nif using zigler was a trivial transformation for claude to do.

Re: Zig – SPIR-V Backend Progress

#56

Post by coxmi »

tremon wrote: post #53
coxmi wrote: post #35

Earlier quoted context omitted.

Yeah, after looking it up, it looks like it is basically only used as either field access or an 'infer operator', is that right? I thought it was used in four completely separate ways: · normal struct field access · anonymous struct definition · field definition within structs (for reasons to do with the parser) · an extra 'infer operator' for syntactic sugar But there's no support for anonymous structs/fields, and a…

I don't think that "infer operator" is a special case of field access, to me it feels like regular known-type elision similar to how C# and C++ use the var keyword if the data type can be inferred from the rhs expression: const Enum = enum {one, two, five}; const t: Enum = .one; // Enum.one, but the type was inferred from lhs std.debug.print("{t}\n", .{t}); Defining an anonymous struct is valid in zig; your example i…

Thanks for the detailed answer :)

All this does for me is raise the question of why they chose to use the `.` for so many different uses. I'd be fine if it was just to infer the type, but it seems very overloaded.

Re: Zig – SPIR-V Backend Progress

#57

Post by fuzztester »

auraham wrote: post #19
laszlojamf wrote: post #3

I 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…

I have the same feeling about Zig. In this interview [1], Andrew Kelley, creator of Zig, explains a lot of the features of the language; compares it against c, rust, go; and explains why he created the language. According to him, the killer feature of zig is the tool chain (compiler, linker, build system) since it has no dependencies. So, it will work in any OS/target you choose. It is a really interesting interview.…

I saw that video just a few days ago and agree that it is quite a good one.

I liked the way Andy talked throughout the video, and also thought the interviewer's questions were very good.

Re: Zig – SPIR-V Backend Progress

#59

Post by Veserv »

epolanski wrote: post #36
noelwelsh wrote: post #29

Earlier quoted context omitted.

What Zig is doing is called "capability passing". I don't know if the Zig team is aware of this field of work, or have independently arrived upon it, but that's what is achieved by passing IO, memory allocators, and other stuff around. The core idea is that you create a "capability" for any action you want to track, such as using IO, allocating memory, or in your example making cross core or cross server calls. Now t…

That looks like a convoluted way to describe dependency injection to me, what am I missing.

Capability passing and dependency injection are just convoluted ways to describe passing parameters instead of using globals.

Capability passing is just extending that to the level of imports. Your files do not import the global I/O library and then use io.print(). They are passed a I/O library as the parameter {io} which defines a print() function and then call io.print().

Post reply on HN