Live data from Hacker News

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

openmymind.net

221–230 of 329 posts

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

#221

Earlier quoted context omitted.

> I don't thing there is any substantial difference between `Option ` and `@Nullable Thing` or `Thing | null` I object to @Nullable and similar arrangements as a magic special case. If the sum types only solved this one issue then it's a wash but they do a lot more too. Either of the sum types, the concrete `Option ` or the ad hoc `Thing | null` are OK because they're not magic, less magic is better.

I’m confused. You seem to think Option is magical? It is not, and neither is Result. They are regular sum types defined in the standard library, nothing special about them.

That's certainly not what I was trying to get across. Perhaps I wrote something confusing, for which I apologise, but, since we're here anyway...

Technically Option is actually magic, though it's for a subtle reason unconnected to the current topic. If you go read its source Option is a langitem, that is, Rust literally isn't allowed to exist without this type. Rust's core libraries are defined, so you shouldn't and most people never will use Rust without them, but the Rust language actually doesn't require that all of core exists, it does require a handful of types, functions etc. and those are called "langitems".

So, why is Option a langitem? Well, Rust's language has for-each loops. But what it actually does (there's literally a compiler step doing this) is treat those loops as if they'd been written as a slightly clunky loop { } block making and then consuming an Iterator. To do that the IntoIterator and Iterator traits must exist, and further as the return type from the next call needed in Iterator is an Option the Option generic type must exist too!

Technically this type wouldn't have to be called Option, the Rust compiler doesn't care what it is called, but it must exist or else the compiler doesn't know how a for-each loop can work.

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

#222
post #195

Earlier quoted context omitted.

The key problem with Zig nowadays is how much of its community and adoption is driven by anti-Rust sentiment. As a result, while Rust puts beginner onboarding and documentation at the center of its culture, as opposed to the “C neckbeard”'s culture, Zig is going the other way around. (Loris Cro being a key community figure isn't helping in any way, and it's a good remainder that if you don't clear up your community f…

That is actually a valid point on expectation given the attracted people's demographic. I will hopefully wait for comments from Ghostty, Bun or Tigerbeetle Devs. On another point that is wroth mentioning, I hope Andrew will at least put it out publicly, IMO Zig isn't Anti-Rust. But it did attract the type of people who are not too happy with Rust. I dont remember a single time Zig came out to bash anything about Rust…

I don't think Andrew is anti-Rust. But Loris, whose hn profile says he's “vp of community of the zig software foundation” is as anti-Rust as you can get: he's pathologically obsessed by Rust and spent significant amount of energy outright insulting Rust maintainers here or on Twitter (when he's not buzzy writing anti-Rust rant on his blog).

But as you say, there's no reason why Zig ought to be anti-Rust, both language are are fresh attempts at low level programming, both highly opinionated and with very different philosophies and trade offs and both language can cohabit peacefully (I've heard good things about using the Zig toolchain for cross compilation of C dependencies in rust projects, so the existence of Zig already has had a positive impact on the Rust ecosystem).

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

#223
post #136

> To convert the Stream.Reader to an std.Io.Reader, we need to call its interface() method. To get a std.io.Writer from an Stream.Writer, we need the address of its &interface field. This doesn't seem particularly consistent. That made me think of how that change would be received in Go (probably would be discarded). They way they approach changes in extremely deep analysis and taking as much time as it needs to avoi…

This wasn't exactly the case before Go 1.0 -- it changed quite rapidly, although in a less fundamental way (for example, removing semicolons, changing error types, etc.), and they usually provided an option to transform code automatically.

It works now that way because they promised it to be stable after 1.0.

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

#224
post #147

Earlier quoted context omitted.

That's ok. "It's an unstable, experimental, early version." is a valid explanation. GP put the lack of docs and the new interface together, which... isn't an excuse.

That Zig is pre 1.0 is a given. Not sure how you could take my statement as ”even post 1.0 releases don’t need docs.”

> Not sure how you could take my statement as ...

I didn't.

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

#225

Earlier quoted context omitted.

> Documentation exists Where does a beginner go to learn how to use the package manager these days? It looks like they still won't find any clues in the "Learn" section of Zig's website. There's a promising page titled "Zig Build System" in there which references a "Package Management" section, but when you click on it, it doesn't exist!

So in your mind, one missing section means "no documentation"? This isn't the checkmate you think it is, you're just moving goalposts. But to answer your question, it exists in the comments of the auto-generated build.zig.zon file

It's not just "one missing section", and we're not just talking about some fringe language feature but the build system which is probably the most complex, important, and under documented part of the language.

The official answer to complaints about missing documentation has always been "ask in Discord". Pretending that this isn't the case is just disingenuous.

> But to answer your question, it exists in the comments of the auto-generated build.zig.zon file

The comments document the file format of build.zig.zon, they don't tell you anything about how to actually use a dependency in your build system.

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

#226
post #11

Earlier quoted context omitted.

You’re not familiar with Zig’s culture, I guess. Complain about the lack of documentation and be prepared for the flood of “just read the stdlib code” helpful comments by pretty much everyone who writes Zig right now. Because most APIs are just as hard to use as in this post (check things like HTTP and even basic file system operations) only the strongest survive.

The key problem with Zig nowadays is how much of its community and adoption is driven by anti-Rust sentiment. As a result, while Rust puts beginner onboarding and documentation at the center of its culture, as opposed to the “C neckbeard”'s culture, Zig is going the other way around. (Loris Cro being a key community figure isn't helping in any way, and it's a good remainder that if you don't clear up your community f…

> anti-Rust sentiment

I have not seen much of any anti-Rust sentiment in the community. There's a lot of people in the community who do Rust, like rust, and work on rust projects. If the Zig community has an anti-anything sentiment, it's against C++.

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

#227

Earlier quoted context omitted.

So in your mind, one missing section means "no documentation"? This isn't the checkmate you think it is, you're just moving goalposts. But to answer your question, it exists in the comments of the auto-generated build.zig.zon file

It's not just "one missing section", and we're not just talking about some fringe language feature but the build system which is probably the most complex, important, and under documented part of the language. The official answer to complaints about missing documentation has always been "ask in Discord". Pretending that this isn't the case is just disingenuous. > But to answer your question, it exists in the comments…

I've added more explanatory comments in the new template that ships with 0.15.1, also you might be interested in this video https://www.youtube.com/watch?v=jy7w_7JZYyw

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

#228
post #109

Earlier quoted context omitted.

> People state these things about Rust's own implementation (or one of the other gazillion safe langs) potentially not being safe all the time Because it's technically true. The best kind of true! Sorry, I meant to say the opposite of truth. Neither Rust nor Ada.Spark, which use LLVM as a backend, can prove via that they are correct if LLVM has bugs. In the same way, I can't guarantee tomorrow I won't be killed by a…

To be fair, although LLVM has several pretty annoying bugs which result in miscompiling Rust (and C, and any other language capable of expressing the same ideas) and it sure would be nice if they fixed them, there are also Rust bugs that live in the Rust compiler itself and aren't LLVM's responsibility. There are some scary soundness holes in Rust's compiler that will get patched eventually but in principle you could…

> To be fair, although LLVM has several pretty annoying bugs which result in miscompiling Rust (and C, and any other language capable of expressing the same ideas) and it sure would be nice if they fixed them, there are also Rust bugs that live in the Rust compiler itself and aren't LLVM's responsibility.

Sure. Again, I didn't say there are no bugs in Rust codebase ever, or that Rust will prevent all of errors forever.

They are working on them, but a large chunk ~50% (45 out of 103) are either nightly-only bugs (due to nightly-only features) or LLVM bugs that are difficult to coordinate/solve.

Some part of them will probably be helped or solved by a new trait resolver, Polonius. Granted, this still won't resolve all issues. Or even all trait related issues.

> There are some scary soundness holes in Rust's compiler that will get patched eventually but in principle you could trip them today.

In principle, yes. In principle you should cower in a corner, because there are many scary things in the world. From microbes, to insects, to malevolent proteins, to meteors, to gamma rays, to strangelets, to rogue black holes, to gravity entering a new stable state.

In practice, you don't. Because in practice we empirically adjust our expectations to the phenomena that occur, or have occurred. So a war is very likely, but being vaporized by a stray cosmic ray is not very likely.

And most of those UB require either strange code or a weird combination of hardware, compilers, or flags. It's probably why most people don't encounter UB in everyday Rust.

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

#229

Earlier quoted context omitted.

That's why I like RAII.

It's a bug to flush (fallible operation) in a destructor (infallible operation).

I know you've thought carefully about these issues, but still it can't be that simple, can it? Closing a file or a socket is a fallible operation too.

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

#230
post #155

Earlier quoted context omitted.

Zig is not really a handmade project, case in point both Andrew and I are blocked on social media by the two gods of the handmade movement (casey and john) and, according to their die hard fans, Andrew gave a talk at the last handmade conference that caused the community to split apart (the reality is a bit more complex than this, but Andrew's talk is certainly one that you wouldn't see at their new "better software"…

Here is another comment on the whole Handmade-Kerfuffle from one of the presenters: https://wiki.xxiivv.com/site/2025.html (the entry under 19b) It seems this was a right vs. left (or liberal) split.

more like old school lib vs "new left"
Post reply on HN