9 ms·
Is Zig's new writer unsafe?
- casey2 1y agoWho cares? seems like something for the issue tracker no?
- hu3 1y agoThe blog author has a history of posting clickbait'ish criticism about Zig.
- scuff3d 1y agoRight, that huge series he wrote as an introduction to Zig and all the articles about specific Zig features were super mean and clickbaity...
- nhanb 1y agoThat's gross misrepresentation. He wrote _lots_ of helpful educational articles on zig that painted it in a good light. I would know because I learned a great deal from his posts when I started with zig. Recently he posted a grand total of 2 articles expressing his confusion/skepticism of new zig features, that's it.
- tialaramex 1y agoThis seems like it's maybe unwise but I can't see how it's unsafe ?
- simjnd 1y agoAndrew Kelley (Zig creator) replied to this on lobste.rs https://lobste.rs/s/js25k9/is_zig_s_new_writer_unsafe#c_ftgczy https://lobste.rs/s/js25k9/is_zig_s_new_writer_unsafe#c_ftgc...
- flykespice 1y ago> Kinda wish the author would attempt to collaborate rather than write stuff like this and I’m too dumb for Zig’s new IO interface but, whatever, it’s their blog so they can do what they want. Damn, Andrew Kelley really come across as a dickhead when taking any bit of criticism about his language, often painting them as bad actors trying to sabotage the language. This isn't the first time he repeats this behavior. EDIT: https://news.ycombinator.com/context?id=45119964 https://news.ycombinator.com/context?id=45119964 https://news.ycombinator.com/context?id=43579569 https://news.ycombinator.com/context?id=43579569
- tristan957 1y agoThat was not my takeaway from his comment at all.
- HextenAndy 1y agoQuite. I don't think it's unreasonable to expect someone to check the issue tracker before blogging and I don't think Andrew's response was at all problematic.
- didibus 1y agoI'd say the only issue what the "too dumb, but whatever" comment. That should have been removed and it would have been totally reasonable. Edit: Oh actually, the author has another blog post titled "I'm too dumb for Zig ...". With that context, it makes sense and I agree it's a reasonable response. I'm sure other readers like me didn't know that context though.
- meisel 1y agoYeah, and his behavior in this LLVM discourse thread made me not want to ever try Zig: https://discourse.llvm.org/t/rfc-libc-taking-a-dependency-on-boost-math-for-the-c-17-math-special-functions/87479/4 https://discourse.llvm.org/t/rfc-libc-taking-a-dependency-on...
- 1y ago
- kaoD 1y agoWhat a terrible way to take constructive feedback. Writing not one but two blog posts takes time and effort, moreso when it includes investigation and examples... the posts are not just low effort "this is crap" rants (and they even blame themselves, even though it's clear from the posts that there are documentation/discoverability issues). What if the poster doesn't feel knowledgeable enough to contribute code? (as shown by his first post title, "I'm too dumb for...") If that's not collaborating I don't know what it is...
- koiueo 1y agoI've read it completely differently. The response IMO is constructive and invites the blog post author for further discussion.
- 9question1 1y agoI think it's likely that both the blog poster and the maintainer are being perceived as more negative in tone than the intent / reality. They both included disclaimers "I must be doing something wrong. And if I am, I'm sorry." and "whatever, it’s their blog so they can do what they want." They're also both giving critical feedback "But, if I'm not, this is a problem right?" "Kinda wish the author would attempt to collaborate rather than write stuff like this" but in both cases the criticism is extremely mildly worded compared to most toxic online discourse. This seems... great? Isn't it good we're able to disagree so politely? It's not toxic to have a disagreement or to give critical feedback. We don't need to all pretend to agree with each other all the time or be happy with each other in order to have a civil discourse.
- wolttam 1y ago"but whatever" are two of the most dismissive words when put together. "I see what you've written, but whatever."
- oofd4 1y ago[dead]
- 1y ago
- wolvesechoes 1y agoThis subthread is peak FOSS world experience - 59 comments discussing who said what, why it was or wasn't nice etc.
- didibus 1y agoI've seen Zig popup a lot recently. What's the value proposition of Zig? It's not immediately obvious to me. Is it kind of like the Kotlin of C, going for a better syntax/modern features but otherwise being very similar?
- logicchains 1y agoIt's a powerful alternative to Rust and C++ for writing ultra low latency code when safety isn't important, like games or HFT. Its standard library and ecosystem have excellent support for passing around allocators and no hidden dynamic allocation (every function that allocates takes an allocator as a parameter), which makes it much harder to hit the latency pitfalls common to Rust and C++. It also encourages the latency-optimal approach of using local bump-a-pointer arena allocators where possible rather than the slow global allocator. And finally, the superior metaprogramming support makes it more convenient to use high performance techniques like struct-of-arrays.
- lossolo 1y agoYour comment was corrected or written by ChatGPT, right? It's super interesting that I can recognize these things now. The specific usage of punctuation, certain words and sentence construction.
- pclmulqdq 1y agoRusty rust and C++-y C++ are both often slower than hand-rolled C for a given function, and zig is intended to be a better way to hand-roll some C. C as a language is obsessed with the fact that C runs everywhere. Even on a DSP with a 24-bit char and a 24-bit int. If you take out those complexities and you add 40 years of lessons on language design, you can make something a lot simpler.
- metaltyphoon 1y ago> Rusty rust and C++-y C++ are both often slower than hand-rolled C for a given function This makes no sense whatsoever and very far from the truth.
- jmull 1y agoI think there's just a bug somewhere, not a general "safety" problem.
- latch 1y agoThen in the top-most snippet, what size should `buffer` be?
- jmull 1y agoIt shouldn't matter. Decompress's Reader shouldn't depend on the size of the buffer of the writer passed in to its "stream" implementation. So that's a bug in the Decompress Reader implementation. The article confuses a bug in a specific Reader implementation with a problem with the Writer interface generally. (If a reader really wants to impose some chunking limitation for some reason, then it should return an error in the invalid case, not go into an infinite loop.)
- latch 1y agoI ... don't disagree with you. Thanks. It helps my understanding. I know this is moving the goalpost, but it's still a shame that it [obviously] has to be a runtime error. Practically speaking, I still think it leaves lot of friction and edge cases. But what you say makes sense: it doesn't have to be unsafe. Makes me curious why they asserted instead of erroring in the first place (and I don't think that's exclusive to the zstd implementation right now).
- thayne 1y agoSo how would the Decompress Reader be implemented correctly? Should it use its own buffer that is guaranteed to be large enough? If so, how would it allocate that buffer? At the very least, the API of the Readera and Writers lends itself to implementations that have this kind of bug, where they depend on the buffer being a certain size.
- kiitos 1y ago> So how would the Decompress Reader be implemented correctly? Should it use its own buffer that is guaranteed to be large enough? yes > If so, how would it allocate that buffer? as it sees fit. or, it can offer mechanisms for the caller to provide pre-allocated buffer(s). in any case the point is that this detail can't be the responsibility of the producer to satisfy, unless that requirement is specified somehow explicitly in general the new zig io interfaces conflate behavior (read/write) with implementation (buffer size(s))
- preommr 1y agoThis feels like it should've been a git issue rather than a blog post. No feedback from the author, no explaining what the code does at a level for people new to zig, no explanations of the fundamental problem (i.e. files, buffers, and flow of data, and how to write that as code) and how it relates to what zig is doing, no alternate solution for how zig or other languages might try to solve the problem. I have a strong suspicion that people are upvoting this based on the title of 'Zig' and 'unsafe' instead of the actual substance of the post.
- paulddraper 1y agoThis is very readable if you know the language, plus a modicum of file I/O.
- bheadmaster 1y agoI've never worked with Zig in my life, and I don't have an opinion on it either. I've heard it's neat. Despite that, this post was intuitively clear to me. Zig's *std.Io.Reader and Writer seem to be abstractions over many types, like Java's interface class, Go's interfaces, C++'s concepts or Rust's traits. However, it seems that abstraction itself is leaky - in that the length of the buffer is an implicit dependency which cannot be known from the type alone. Admittedly, we don't know if there's a good explanation for the behavior - but then again, HN comments are as good a place to learn as any. Maybe someone will come up and explain.