https://lobste.rs/s/js25k9/is_zig_s_new_writer_unsafe#c_ftgc...
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.
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.
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...
The response IMO is constructive and invites the blog post author for further discussion.
> Kinda wish the author would attempt to collaborate rather than write stuff like this [...] but, whatever, it’s their blog so they can do what they want.
...feels like passive aggression. In particular the "stuff like this" (like what?) and "but, whatever" felt very unnecessary and the whole "I wish he'd collaborate on my terms" is IMO uncalled for.
I'm glad you made the note about that part though, I agree with it and we can always do better.
Make blog posts, it's great!, but if you don't think you're the expert then they'll go a lot farther for everyone if you put 5% of the work of doing so into engaging with the community about it for additional insights first. That's a fair note to make, though I agree the ending could be less passive aggressive about those who don't want to engage with the community.
Blog posts are collaboration (1). I did get the sense that Andrew doesn't see it that way. (And for this post in particular, and writegate in general, I have been discussing it on the discord channel. I know that isn't an official channel).
My reasons for not engaging more directly doesn't have anything to do with my confidence / knowledge. They are personal. The linked issues, which I was aware of, are only tangentially related. And even if they specifically addressed my concerns, I don't see how writing about it is anything but useful.
But I also got the sense that more direct collaboration is welcome and could be appreciated.
(1) - I'm the author of The Little MongoDB Book, The Little Redis Book, The Little Go Book, etc... I've always felt that the appeal of my writing is that I'm an average programmer. I run into the same problems, and struggle to understand the same things that many programmers do. When I write, I'm able to write from that perspective.
No matter how inclusive a community you have, there'll always be some opinions and perspectives which get drowned out. It can be intimidating to say "I don't understand", or "it's too complicated" or, god forbid, "I think this is a bad design"; especially when the experts are saying the opposite. I'm old enough that I see looking the fool as both a learning and mentoring experience. If saying "io.Reader is too complicate" saves someone else the embarrassment of saying it, or the shame of feeling it, or gives them a reference to express their own thoughts, I'm a happy blogger.
The members of the Zig project are free to reach out to the author!
When you create a project in public people will write about it, tweet about it, complain about it, etc (if you’re lucky!).
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?
I’m ranting but based the Rust/Zig discussions here on HN and the number of segfault issues in the Bun repo there is a core of truth.
But it’s not only the language itself, it is also the tooling around it. Single unit of compilation has some nice properties, allowing to support colorless async. Fast compile times. Being able to use existing C code easily and having optimization across language boundaries. Cross compilation out of the box. Generally caring for performance in all aspects.
So for me it is a better C, low-level but still approachable and not having so much cruft.
tialaramex•1h ago