Live data from Hacker News

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

openmymind.net

121–130 of 329 posts

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

#121
post #114
post #110

Earlier quoted context omitted.

> […] Zig was still using the bootstrap compiler written in C++ that would not free memory […] That sounds strange. Modern C++ requires very little manual memory management, at least when you're writing something high-level like a compiler. C++11 had been out for years when development on Zig started. Were they writing C++ old-school as C-with-classes and malloc() everywhere? Why not use a more appropriate language f…

IIRC, it was a performance thing, and it's not an uncommon pattern in CLI tools. Freeing memory can actually cost you performance, so why not just let the OS clean up for you at exit(2)?

> IIRC, it was a performance thing […]

Why would you care about these kinds of micro-optimizations at that stage of development, when you don't even know what exactly you need to build? We're not talking about serious algorithmic improvements like turning O(n²) into O(n) here.

> Freeing memory can actually cost you performance, so why not just let the OS clean up for you at exit(2)?

Because a compiler is not some simple CLI tool with a fixed upper bound on resource consumption.

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

#122
post #96

Earlier quoted context omitted.

C is entirely as complicated as Rust, if your goal is to write correct software that doesn't crash all the time. It's only a syntactically simple language. Actually making anything interesting with it is _not_ simple.

https://github.com/oxidecomputer/omicron/blob/5fd1c35/nexus/...

Yuck. I thought some of the signatures you end up with when building “Modern C++” in the Andrei Alexandrescu style were hairy, but this looks sick. Not in a good way.

Probably does something cool for all that crazy though?

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

#123
post #6

Earlier quoted context omitted.

Only if use after free story actually gets fixed, and not by repurposing what has already existed in the C and C++ ecosystems for the last 30 years, like PurifyPlus or VC++ debug allocator.

If you mean running clang-tidy as a separate build step or ASAN in a different category than other soundness checks? Compute is getting tight, lots of trends, the age of C++ is winding down gracefully. The age of Zig is emerging delibetately, and the stuff in the middle will end up in the same historical trash bin as everything else in the Altman Era: the misfortunes of losing sight of the technology.

> The age of Zig is emerging delibetately

Pet projects are nice, but slow down with the copium intake.

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

#124
I… will not update my zig side projects to 0.15.x. I can see why Andrew wanted to release this, and I can appreciate getting the new Io in people’s hands… but it’s merely a few weeks after merging massive amounts of breaking changes on readers and writers.

For those working on the standard library, it’s a great thing. For one like me who casually uses zig, it feels like waiting for 0.16.0 for most of the IO dust to settle is the right thing to do.

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

#125
post #96

Earlier quoted context omitted.

C is entirely as complicated as Rust, if your goal is to write correct software that doesn't crash all the time. It's only a syntactically simple language. Actually making anything interesting with it is _not_ simple.

https://github.com/oxidecomputer/omicron/blob/5fd1c35/nexus/...

This is an extremely generic interface to some meta magic DSL. It's complex but not really that complicated and yeah, it's going to be a bit long. But that's going to happen in every language where you rely on types for early validation.

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

#126

I'm not a Zig PM but the first obvious fix for the issues the OP wrote about is to write better documentation, including usage examples (the more the better, almost to a fault). Also doubles as a good time to reflect on whether the user is having to do too much. If the tradeoff was absolute performance/avoiding introducing load-bearing performance-lowering abstraction I think that goal was achieved, but DX may have g…

Writing good docs/examples takes a lot of effort. It would be a waste considering the amount of churn that happens in zig at this point.

That's a false dichotomy, I'll take minimal bitrotten docs in a community wiki over no docs. There's no excuse not to at least have a stub that says "these features are evolving quickly but here are 10 open source projects that should serve as good references".

Something - anything. As much as I like Zig, I dread returning to it after a few months of being out of the loop.

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

#127
post #39
post #29

Author here. I finally got it working. I had to flush both the encrypted writer and then the stream writer. There was also some issues with reading. Streaming works, but it'll always return 0 on the first read because Writer.Fixed doesn't implement sendFile, and thus after the first call, it internally switches from streaming mode to reading mode (1) and then things magically work. Currently trying to get compression…

Ha, "Don't Forget to Flush" https://www.youtube.com/watch?v=f30PceqQWko

That's why I like RAII.

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

#128

Earlier quoted context omitted.

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.

Let me answer your question with a question - how do you memory map in rust with the standard library? In zig it's std.posix.mmap.

    extern "C" mmap(addr:*mut c_void, length:c_size_t, prot:c_int, flags:c_int, fd:c_int, offset:c_ssize_t) -> *mut c_void;
Piece of cake. Or you could install a crate with bindings if you are afraid of writing code yourself.

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

#129
post #111
post #2

I have never understood libraries or imterfaces that want me to allocate buffers for their type. I can't parse them (no need for the lib then) or write to them (would probably break the exchange). The weird interface of go is probably due the fact that some interfaces can be used to extemd the writer like the hijacker interface (ResponseWriter.(http.Hijacker)) and the request object is used multiple times with differ…

> I have never understood libraries or imterfaces that want me to allocate buffers for their type. That doesn't seem that odd to me. It's a trade off: more flexibility, but more manual work. Maybe I have a buffer that I've allocated that I'm not using anymore (say I have a buffer pool) and want to use it again. If the type allocates its own behind the scenes, I can't do that. Or maybe I'm working in an environment wh…

> If the type allocates its own behind the scenes, I can't do that.

Isn't that the reason why Zig passes around allocators everywhere? If you're using a buffer pool, you should probably be handing out some kind of buffer pool allocator.

Requiring all allocation to have happened before execution is still a good reason to pass buffers around, but I feel like the other situations you describe can be solved by just passing the right allocators.

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

#130
post #96

Earlier quoted context omitted.

C is entirely as complicated as Rust, if your goal is to write correct software that doesn't crash all the time. It's only a syntactically simple language. Actually making anything interesting with it is _not_ simple.

https://github.com/oxidecomputer/omicron/blob/5fd1c35/nexus/...

Typing code from hell for sure, but how would you write an API with the same guarantees in C? Some kind of method specific struct that composes all other kinds of structs/unions to satisfy these requirements?
Post reply on HN