Is Zig's New Writer Unsafe?

Quite. 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.

I'm guessing you never tried Linux either

That all seemed pretty adult and tame. Maybe slightly stand-offish at worst. And I tended to agree with Andrew in that thread. A project like Zig is an absolutely massive undertaking. I can cut Andrew some slack. Not everyone is perfect all the time, and his behavior there was nowhere close to BS I have seen in other open source projects. Ahem, Linus.

From his "Open Letter to Everyone I've Butted Heads With":

> My friend - it's not personal. I care about you. I actually do value your opinion. I'm interested in your thoughts and feelings. I want to make you happy. I'm sad that I can't serve you better with my open source project. I want to. I wish I could.

> I'm hustling. I'm playing the game. I'm doing what it takes to make this thing mainstream and a viable, practical choice for individuals and companies. If you talk shit about Zig in public, I'm going to fight back. But I respect you. I see you. I understand you. I don't hate you. I would literally buy you a drink.

https://andrewkelley.me/post/open-letter-everyone-butted-hea...

EDIT I totally missed the context

Yea I think my post came off as insulting which I didn't mean at all (I particulary don't consider "dickhead" as insult but more a synonym for bad character)

I have nothing against him at all or his language (in fact I hope it further replaces C dominant position in embedded systems and low level programming), I just wish he toned down his passive attitude against criticism acting in good faith.

"but whatever" are two of the most dismissive words when put together. "I see what you've written, but whatever."

I 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.

Might be cultural differences but, to me...

> 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 think it's a reasonable response aside from the last sentence aside.

Author is posting honest and respectful critique of Zig features on their blog. That is a valid way of collaborating in the community discussion. The project github isn't the only place where discussion is allowed to take place.

Author here. I see it both ways.

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 complicated" 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.

Why is this counter-productive and self promotion? Does that mean we should all stop writing programming related blog posts? And move all the discussions into GitHub issues only?

Nah, this is absurd. This guy or anybody else can write whatever they want, whenever they want, on their own blog. They are under zero obligation to create bug reports, file issues, check in on a chat channel, or contribute in any other way to an open source software project that does not employ them. Writing blog posts is a perfectly reasonable and normal community behavior.

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!).

  > Collaborating would be contacting the Zig team through one of the many channels available and asking questions, offering suggestions etc.

  > So what was the point in saying this? Do you think people believe anything contrary to what you said?

This reads to me like an attempt at polishing a pig.

Just hide all issues people using your project stumble upon in internal mailing lists and project a polished facade.

This reads like an issue anyone can stumble upon with the answer being ”you’re holding it wrong”.

I want to find that from a quick search rather than wading through endless internal discussions.

Rusty rust?

I don't think there is such a specific thing and certainly disagree that all idiomatic rust is somehow slower by default.

You can write rust like you might write a higher level language and then that can end up slower but if you write idiomatic low level rust, the performance is much harder to compare with C. There are things which will be faster in C and things which will be faster in Rust but broadly things will be extremely similar in performance.

I write bare metal embedded rust a lot these days and there are quite complex concepts you can represent in rust which make your code a lot safer without a performance hit.

> 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.

Crashes from safety bugs are rare in HFT because they can replay years of data against code changes. For a strategy that trades in and out of positions quickly and is flat most of the time, it's also often not a big deal if the program crashes in the midst of running, as long as some technique has been arranged to cancel resting orders and alert a trader (who is generally monitoring the system's operations at all times).

They're certainly not inclined to pursue safety at any expense of performance in their code.

> modern online gaming with microtransactions

I don't think anyone should develop such games either

>Safety not important in HFT? You'd better make sure those precious microseconds buy you enough to make up for when things go awry.

Memory safety bugs are very rare in modern, well-written and tested C++. The key difference is that there are no adversarial inputs, while something like a browser or server needs to deal with potentially adversarial inputs, making absolute memory safety much more important (as even a single memory safety issue could be exploited).

“Safety” as defined in the context of the Rust language - the absence of Undefined Behavior - is important 100% of the time. Without it, you are not writing programs in the language you think you are using.

That’s a convoluted way to say that UB is much, much worse than you think. A C program with UB is not a C program, but something else.

Which is written in C/C++. Showing that Zig is not moving the needle on UB when a project becomes sufficiently complex.

Take a look at Deno and check the percentage coming from FFI with unsafe languages.

https://github.com/denoland/deno/issues?q=Segfault

The question that matters is how many deno has.

How is Rust anti zig if it came first?

AST macros are very powerful. As to them being "good", that's debatable. They have advantages but also disadvantages. For one, they operate on syntax, so they're a separate metalanguage and not so pleasant to debug. For another, they are referentially opaque (i.e. when passed different expressions with the same meaning, they can produce different results), which makes them powerful but also mysterious.

What's interesting about Zig's comptime is that while it's strictly less powerful than AST macros, it can do a lot of what macros can do while not being a metalanguage - just Zig.

Not only being text based but also having another separate language is problematic. Rust also has powerful declarative macros but it is it’s own language. Procedural macros and crabtime are imho a bit better for more complex cases as you write Rust.

To be clear, we all know GP is talking about C macros.

> On the other hand, this doesn't sound to me like an upside. Of course it's fine and well if it's easy to do this. But hopefully you'd prefer not to have to... ?

Why wouldn't you? You can often make your code simpler and more performant by using certain allocation strategy rather than relying on global allocator. Malloc/Free style strategy is also very error prone with complex hierarchical data structures where for example arena allocation can tie the whole lifetime to a single deallocation.

> Would appreciate some explanation of the theory here. Though it does occur to me that the languages I can easily think of with "coloured" async also don't exactly statically link everything all the ti

Async is moot point, it does not exist in zig right now, it used to but it was removed. There are plans to reintroduce it back, but using async as any sort of benefit for zig is not being honest.

Comptime is very nice but certainly more limited then Lisp. You can't generate arbitrary code with it. But good enough to implement something like JSON serialization or Struct-of-Arrays in normal code that is readable.

Custom allocators are very nice. We are very much in manual memory management + optimization territory here. Having things like arena allocators makes a lot of difference in specific use-cases when you want/need every bit of performance. Also nice being able to switch the allocator for tests that is able to report leaks for example.

Yes, hidden control flow I mean something like exceptions, RAII or Rust's Dispose. So more a comparison to other languages than C.

The explanation I would refer to the talks "Don't forget to flush" or "Zig Roadmap 2026" from Andrew Kelley. Also the blog post "Zig's New Async I/O". I think it has something to do with being able to infer the required size of the stack, but already forgot the details.

https://kristoff.it/blog/zig-new-async-io/ https://youtu.be/f30PceqQWko?si=g2nLTE4ubWD14Zvn https://youtu.be/x3hOiOcbgeA?si=SUntYOYNOaxCRagc&t=3653

As to compared to Rust. The fast compile times are nice. Having a small language that you actually can understand helps to be productive. Not being restricted by the borrow checker makes it easier to implement some low-level things. Just being able to import most C code without wrapper makes the smaller ecosystem a much smaller problem. Rust is nice and certainly a good pick for many cases, but personally I often feel overwhelmed by the complexity and tons of tons of types for everything.

Many of those warts were already not present in other systems languages predating C, and others of similar age.

It has proper arrays and slices, even being able to define a sentinel value in the type system, so you know when it is a C string or a slice with a specific size with arbitrary values. Strings can become a problem if you need another encoding than the chosen one. Then you start to use byte slices anyway. You need to allocate a new one if you want to change just a part of it. Safer yes, but can produce unwanted overhead and you have to duplicate many APIs for strings and byte arrays as it is the case in Go.

It feels like C but raised with Java as its strict stepfather.

You can ofc use the *alloc from libc if you want. Otherwise there are different ones in the standard library, ArenaAllocator wraps another allocator, FixedBufferAllocator uses a given byte slice. I recommend to take a look at https://ziglang.org/documentation/master/std/#std.heap to get an overview.

Looks general purpose to me. What purposes couldn't you use Zig for? A general-purpose programming language isn't necessarily good for every purpose but it can be used. For example both Java and C are general purpose languages. Should you write an OS kernel in Java? Maybe that's unwise but people did. Should you write a web browser in C? Again unwise but people did.

Some languages aren't like this. You can't write an OS kernel in WUFFS for example and that's on purpose, that's not what WUFFS is for.

Given their level of adoption, those languages represented what their creators thought, not necessarily what the industry thought.