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

I'm too dumb for Zig's new IO interface

openmymind.net

Post reply on HN
Print view View original

41–50 of 329 posts

Re: I'm too dumb for Zig's new IO interface

#41

Post by konart »

LAC-Tech wrote: post #15
8s2ngy wrote: post #10

I’m sorry, but any non-trivial Zig code gives me PTSD flashbacks of C. I don’t understand who Zig is targeting: with pervasive mutability, manual allocation, and a lack of proper sum types, it feels like a step back from languages such as Rust. If it is indeed a different way to write code, one that embraces default memory unsafety, why would I choose it over C, which has decades of work behind it? Am I missing some…

Zig is a systems programming language. I think that's probably who it's targeting. People do systems programming in rust, but that's not really what most of the community is doing. And it's DEFINITELY not what the standard library is designed for.

>People do systems programming in rust, but that's not really what most of the community is doing.

As someone who haven't done any systems programming after university: wait, what?

I was under impression that this is exactly what people where doing with Rust.(system apps, even linux kernel, no?)

If not - what do they (most if the community) are doing with Rust?

Re: I'm too dumb for Zig's new IO interface

#42

Post by sshine »

ksec wrote: post #24
hardwaresofton wrote: post #20

Earlier quoted context omitted.

Yeah, thinking about this attitude positively, maybe it’s a feature — if only hard core people can comfortably figure it out, you get higher quality contributions? Not trying to imply that’s an explicit goal (probably instead just a resource problem), but an observation

I think it is a trade off for between zig's development speed and documentation. It is Pre 1.0, extreme beta mode with lots of breaking changes. Generally speaking I think it is the right trade off for now. Purely inferring from Andrew and the Zig's team online character as I don't know them in person, I think they do care a lot of DX, things like compiling speed and tools. So I think once 1.0 come I won't be surpris…

Unstable APIs are a good example of something that's extremely valuable early on.

They unarguably cause confusion for everyone as they change.

But it lets you choose the right abstractions that are going to stick for decades.

If you're going to make a python2 -> python3 transition in your language, make sure it's X0 -> X1.

Re: I'm too dumb for Zig's new IO interface

#43

Post by simonask »

benreesman wrote: post #25
pjmlp wrote: post #18

Earlier quoted context omitted.

I mean those and other ones, we already have enough unsafe languages as it is. The age of C++ is going great, despite all its warts and unsafety, thanks to compiler frameworks like GCC and LLVM, games industry, GPGPU and Khronos APIs. Even if C++ loses everywhere else, it has enough industry mindshare to keep being relevant. Same applies to C, in the context of UNIX clones, POSIX, Khronos, embedded. Being like Modula…

Haskell makes guarantees. Modern C++ makes predictions to within a quantifiable epsilon. Rust makes false promises in practical situations. It invented a notion of safety that is neither well posed, nor particularly useful, nor compatible with ergonomic and efficient computing. It's speciality is marketing and we already know the bounding box on its impact or relevance. "Vibe coding" will be a more colorful and bette…

There is almost nothing accurate about this comment.

"Makes predictions to within a quantifiable epsilon"? What in the world do you mean? The industry experience with C++ is that it is extremely difficult (i.e., expensive) to get right, and C++20 or newer does not change anything about that. Whatever "epsilon" you are talking about here surely has to be very large for a number bearing that sobriquet.

As for the mindless anti-Rust slander... I'm not sure it's worth addressing, because it reflects a complete lack of the faintest idea about what it actually does, or what problem it solves. Let me just say there's a reason the Rust community is rife with highly competent C++ refugees.

Re: I'm too dumb for Zig's new IO interface

#44

Post by hardwaresofton »

ksec wrote: post #24
hardwaresofton wrote: post #20

Earlier quoted context omitted.

Yeah, thinking about this attitude positively, maybe it’s a feature — if only hard core people can comfortably figure it out, you get higher quality contributions? Not trying to imply that’s an explicit goal (probably instead just a resource problem), but an observation

I think it is a trade off for between zig's development speed and documentation. It is Pre 1.0, extreme beta mode with lots of breaking changes. Generally speaking I think it is the right trade off for now. Purely inferring from Andrew and the Zig's team online character as I don't know them in person, I think they do care a lot of DX, things like compiling speed and tools. So I think once 1.0 come I won't be surpris…

On the one hand, I totally get that pre 1.0 is the wild west (somewhat) and should be. The team is right in jealously guarding their ability to make changes.

That said, others have pointed out that writing documentation and tests helps improve quality quite a bit, and in this case it would also increase usability. I think I'd agree with this stance, but there is no way I could make the statement that even most of the code I've written for public consumption had excellent documentation or examples. So I've got no leg to stand on there, just the armchair.

> And I would argue, writing good, simple, clear, detailed documentation is actually harder than writing code itself.

All the more reason why it must be done! A little silly but from my armchair maybe it's one of those "start with the interface you want and work backwards", but the problem is that approach can be at odds with mechanical sympathy and we know which side Zig lands on (and arguably should land on based on it's values).

Re: I'm too dumb for Zig's new IO interface

#45

Post by simonask »

ozgrakkurt wrote: post #12
8s2ngy wrote: post #10

I’m sorry, but any non-trivial Zig code gives me PTSD flashbacks of C. I don’t understand who Zig is targeting: with pervasive mutability, manual allocation, and a lack of proper sum types, it feels like a step back from languages such as Rust. If it is indeed a different way to write code, one that embraces default memory unsafety, why would I choose it over C, which has decades of work behind it? Am I missing some…

Compared to C: Discriminated unions, error handling, comptime, defer. Better default integer type casting, ability to choose between releaseSafe/releaseFast And probably other things. As for comparison to Rust, you do want very low level memory handling for writing databases as an example. It is extremely difficult to write low level libraries in Rust

I think the argument is that it is also extremely difficult to write low level libraries in Zig, just as it is in C. You will just only notice the difficulty at some later point after writing the code, potentially in production.

Re: I'm too dumb for Zig's new IO interface

#46

Post by flohofwoe »

8s2ngy wrote: post #10

I’m sorry, but any non-trivial Zig code gives me PTSD flashbacks of C. I don’t understand who Zig is targeting: with pervasive mutability, manual allocation, and a lack of proper sum types, it feels like a step back from languages such as Rust. If it is indeed a different way to write code, one that embraces default memory unsafety, why would I choose it over C, which has decades of work behind it? Am I missing some…

> a lack of proper sum types

Do you consider Rust enums 'proper sum types'? If yes what are Zig's tagged unions missing?

E.g.:

    const Variant = union(enum) {
        int: i32,
        boolean: bool,
        none,

        fn truthy(self: Variant) bool {
            return switch (self) {
                Variant.int => |x_int| x_int != 0,
                Variant.boolean => |x_bool| x_bool,
                Variant.none => false,
            };
        }
    };

Re: I'm too dumb for Zig's new IO interface

#47

Post by LAC-Tech »

konart wrote: post #41
LAC-Tech wrote: post #15

Earlier quoted context omitted.

Zig is a systems programming language. I think that's probably who it's targeting. People do systems programming in rust, but that's not really what most of the community is doing. And it's DEFINITELY not what the standard library is designed for.

>People do systems programming in rust, but that's not really what most of the community is doing. As someone who haven't done any systems programming after university: wait, what? I was under impression that this is exactly what people where doing with Rust.(system apps, even linux kernel, no?) If not - what do they (most if the community) are doing with Rust?

Web servers, games, and applications, that sort of thing.

Some people definitely do systems programming in, but it's a minority. The std library is not set up for it at all, you need something like rustix, but even that results in very unidiomatic ("unsafe") rust code.

In Zig it's all in the std library by default. Because it's a systems programming language, first and foremost.

Re: I'm too dumb for Zig's new IO interface

#48

Post by simonask »

LAC-Tech wrote: post #15
8s2ngy wrote: post #10

I’m sorry, but any non-trivial Zig code gives me PTSD flashbacks of C. I don’t understand who Zig is targeting: with pervasive mutability, manual allocation, and a lack of proper sum types, it feels like a step back from languages such as Rust. If it is indeed a different way to write code, one that embraces default memory unsafety, why would I choose it over C, which has decades of work behind it? Am I missing some…

Zig is a systems programming language. I think that's probably who it's targeting. People do systems programming in rust, but that's not really what most of the community is doing. And it's DEFINITELY not what the standard library is designed for.

Which part of the Rust standard library are you referring to here?

As far as I can tell, it contains many, many features that are irrelevant outside of systems programming scenarios with highly particular needs.

Re: I'm too dumb for Zig's new IO interface

#49

Post by sureglymop »

aDyslecticCrow wrote: post #33
jakobnissen wrote: post #17

Earlier quoted context omitted.

There is a cost to writing documentation - it takes time, which could be used to improve Zig in other areas. For code that is work-in-progress, it can make sense to not document until things are more settled. Of course documentation is good. But if you have to prioritize either a new feature, or a critical bugfix, or documentation, you often can't have it all

Then they should not have relead the new api at all. Why release half finnished library.

Because the language is not stable at this point and hasn't reached 1.0?

Are you saying one should never make anything half finished available to the public? This post proves why it is valuable to do so, they are getting valuable feedback and a discussion on hacker news for free.

Re: I'm too dumb for Zig's new IO interface

#50

Post by hardwaresofton »

chrisandchris wrote: post #36
hardwaresofton wrote: post #20

Earlier quoted context omitted.

Yeah, thinking about this attitude positively, maybe it’s a feature — if only hard core people can comfortably figure it out, you get higher quality contributions? Not trying to imply that’s an explicit goal (probably instead just a resource problem), but an observation

Contributions to the Zig language or contributions to software using Zig (the latter is the one the post is about as I understand)? If so, I believe Zig will stay within a niche. Lower entry barriers allow "script kiddies" to easily start withe language, and they eventually will become leading engineers. Only a few people tend to go straight for the highest practice without "playing around". IMHO the reason, why PHP…

> Contributions to the Zig language or contributions to software using Zig (the latter is the one the post is about as I understand)?

Yes.

I think a contributor that really wanted to help the ecosystem would start in the stdlib and then start moving outwards. Even if it was LLM-assisted, I think it could be high value.

IIRC Loris already has an engine for building websites with Zig, but making sure that every Zig library has docs (similar to rustdocs) might be a great start. It is incredibly useful to have a resource like rustdocs, both the tooling and the web sites that are easily browsable.

Again, maybe everyone in the Zig ecosystem just has amazing editor setups and massive brains, but I personally really like the ease of browsing rustdoc.

> If so, I believe Zig will stay within a niche. Lower entry barriers allow "script kiddies" to easily start withe language, and they eventually will become leading engineers. Only a few people tend to go straight for the highest practice without "playing around". IMHO the reason, why PHP got so popular (it was not good back then, just very very easy to start with).

I agree, but I'd add that the niche they're aiming for is systems programming, so they're probably fine :). The average hacker there is expecting C/C++ or to be near the metal, and I think Zig is a great fit there. They're likely not going to convince people who write Ruby, but it feels reasonable for C hackers.

Also I want to just be clear that I think Zig has a lot of motivating factors! They're doing amazing things like zig cc, unbelievably easy, "can't believe it's not butter" cross-compilation, their new explicit/managed I/O mechanism, explicit allocators as a default, comptime, better type ergonomics. It's a pretty impressive language.

Post reply on HN