[sramsay]

For me, it's the library problem. I read the guide and think, "Wow, this is really great!" Then I read the cookbook, and it mostly says that things (like database connectivity, regex, options parsing, even HTTP GET) are not quite ready for prime time, and I should just call out to C.

Obviously, it takes time for a language to get there; I don't really mean this as a criticism. But I'm just not interested in wrapping C libraries while I wait for a zig version. I'd rather just write C. Or work in a language that is there with these kinds of things.

[pyrolistical]

Since c abi powers the world, with zig’s ability to easily wrap c libs, not only does zig have access to all libs; it also makes it easy to integrate zig with any existing project as most programming languages have integration with c.

This is why everybody says just use some existing c lib

[sramsay]

Hmm. I could substitute lots of languages for zig in that first sentence. But that doesn't invariably lead the communities that maintain those languages to utter the second.

I also doubt I have space to enumerate the languages that claim to "easily wrap c libs." None of them easily do that. That statement imagines that there's some basic consistency between APIs (and that those APIs are asking for and returning fairly simple types).

[lukaslalinsky]

The thing is, all valid C types are also valid in Zig. You just `@cImport` the header file and use it. You don't need to wrap the API, you just use it.

[pyrolistical]

I would argue zig had the best c integration. This is why it’s different.

[sramsay]

Better than C++? Better than Lua?

[throwawaymaths]

arguably Zig's c integration is better than c's c integration.

[sramsay]

How so?

(If you're hearing a combative tone, it's unintended; I'm asking seriously, because I would love for this to be true!)