Zig Is Self-Hosted Now, What's Next?

I've been learning Zig by porting my toy SQL database in Go to Zig (both projects are on Github, you can go find them if you'd like). This is my first time trying to seriously use a non-GC language for a project, so there's a big learning curve unrelated to Zig in particular. However, it's much easier than trying to learn C (which I've tried a few times). The standard library is incredibly feature rich compared to C (although I've heard whispers that eventually they plan to reduce the size of the standard library, which I'd personally find sad). defer is awesome. comptime too.

I haven't noticed miscompilation yet but I have noticed occasional unclear error messages such as it pointing at the wrong line. I've meant to make a note of these but since I'm just focused on learning I haven't done a great job of writing down these minor bugs.

I don't think the breaking changes (which haven't seemed that big) are a huge deal for most folks curious about PL in general. And I think the potential for being a better C is just so great that it's worth continuing to try out Zig and follow it's development. In particular I think it would make a lot of sense as a teaching language for the college courses that would otherwise use C. And I think it would be a pretty fancy compilation target for language implementations like Chicken Scheme that otherwise target C. (I'm sure it would be great in other situations too but these two are ones I can relate to most.)

But I'm still early on in my exploration of Zig. (Disclaimer: the company I work for uses Zig and sponsors ZSF.)

I hope Zig continues to ship clang, because Zig is the easiest way to install clang.

The person you are replying to (me) is the author of that post.

> The misunderstanding that post makes is that function coloring refers to at compile time.

The original function colors post referred to runtime, so you're wrong.

> In other words, in Zig you don't need to write two versions of a function to use it in async vs sync context.

This is correct, if you only care about compile time.

> Obviously the functions will have different runtime representations, so if you do something that cares about runtime calling conventions or w/e then yes you do need to worry about how the function is used, which is unavoidable.

So you admit that Zig does have function colors?

Also, according to the actual Zig documentation, which I quote in my post, there is only one version of every function; if a function is used in an async context, even if it is sync otherwise, the compiler makes the function async and continues on its merry way, so there is only one runtime representation of a function.

Here's the quote from the documentation:

> Zig infers that a function is async when it observes that the function contains a suspension point. Async functions can be called the same as normal functions. A function call of an async function is a suspend point.

Saying that Zig does not have function colors because it hides them at compile time is a little disingenuous, in my opinion. It still has them, but like a statically-typed language with type inference, it just hides that fact, but only at compile time.

> We can't hide in a cave to build everything in secret until it's ready because otherwise we wouldn't have the money to pay contributors, or we would be forced to get funding through other means (I mention that point in the blog post).

Can you see though how this model can cause a lack of trust in external observers? Your development model is reliant on attracting attention to drive funding. There are some major incentive problems here. I want to be clear that I am not suggesting that you are deliberately doing this but your model actually incentivizes building a lower quality product. You just need to make something appealing enough that people start using it and then, once they are invested in the language, some of them may be willing to pay you to fix the issues they find or build new features that would be useful to them. If the language didn't have issues, there would be no reason to pay you to fix them.

I know I will likely get downvoted for this but I believe in what I say.

> Your development model is reliant on attracting attention to drive funding.

Yes, what alternative do you recommend? VC funding? You think any other financing model would result in being less reliant on attention as opposed to enhancing the effect?

> I want to be clear that I am not suggesting that you are deliberately doing this but your model actually incentivizes building a lower quality product.

You're writing this in a discussion about us having just spent two years reimplementing the compiler to pay tech debt, instead of doing any of the things that you mentioned.

I have to admit that your post smells a bit of concern trolling, especially considering that we've seen a bunch of that in the last few weeks.