4 ms·
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 allocator
by Cloudef 3mo ago
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.
- laszlojamf 3mo agoI 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?
- chaz72 3mo agoI 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.)
- PunchyHamster 3mo ago>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
- chaz72 3mo agoMy specific reply was to laszlojamf saying “it seems like go, but with manual allocation”. To your point though, if Rust is getting it done, go for it. A lot of people still write those in C though.
- pjmlp 3mo agoYes they do. Only those with anti-GC bias don't. Which is why TamaGo, TinyGo and gVisor exist.
- dnautics 3mo agoa 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 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/memory/allocation.hpp https://github.com/openjdk/jdk/blob/master/src/hotspot/share... postgres has at least 8: https://github.com/postgres/postgres/blob/master/src/backend/utils/mmgr/README 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.
- nesarkvechnep 3mo agoJust yesterday I was thinking about the BEAM and would it be tidier if it were written in Zig.
- pjmlp 3mo agoJVM has surely more than 5, because the ecosystem enjoys multiple implementations.
- coxmi 3mo agoThe dot syntax used everywhere really confuses me. I get its use in struct fields, or for defining anonymous structs, but what is this one for? (Some kind of module-level enum space, where .sampler and .unknown are defined previously?) const Sampler = @SpirvType(.sampler); ^ const Image = @SpirvType(.{ .image = .{ .usage = .{ .sampled = u32 }, .format = .unknown, ^ } }); Everything else about zig is quite readable, but this gets me every time. Maybe I'm being dumb though.
- thrwyexecbrain 3mo ago"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.
- coxmi 3mo agoYeah, 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 all structs and fields require a type somewhere for it to be inferred. Which is why this is invalid zig: const test = .{ .x = 0, .y = 1 }; (It would need the type to be specified in the called function definition, or inline when assigning) Correct me if I'm wrong here! (And thank you)
- tremon 3mo agoI 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 }