> The key problem with Zig nowadays is how much of its community and adoption is driven by anti-Rust sentiment. As a result, while Rust puts beginner onboarding and documentation at the center of its culture, as opposed to the “C neckbeard”'s culture, Zig is going the other way around.
Maybe, or maybe the fact that Zig is a small independent project with limited resources has also something to do with it, and this kind of shaming says less about Zig than you'd think.
When I first joined the Zig project, Zig was still using the bootstrap compiler written in C++ that would not free memory (it took more than 4GB to compile the Zig compiler). Some people at the time were asking us to prioritize work on the package manager but Andrew rightfully wanted to prioritize rewriting the compiler instead. In hindsight this was the obviously right decision: a package manager implies that one can very easily add an order of magnitude more code to their project, stressing the performance of the compiler. If we had not prioritized core infrastructure over giving people what they wanted faster, today we would have people complaining that adding a single dependency to their project makes the build impossible to complete.
The Zig project has a huge scope and we are a small independent organization. This makes us extremely nimble and efficient, but it does mean that we need to do things in the order that makes the most sense for the project, not for what the public wants.
The fact that we develop in the open doesn't mean that the language is ready yet.
People that already have the required domain knowledge (and who have a tolerance for breaking changes) will have the opportunity to be early adopters if they wish to do so, others will have to wait for Zig to become more mature. And we do make this clear in releases and all forms of public communication.
We have gone a long way since the bootstrap compiler days, but we are still missing key infrastructure:
- we have a x86_64 custom backend but aarch64 is not complete yet
- incremental compilation is showing that we can get instant rebuilds of large projects, but it has missing features and it doesn't work on all platforms yet
- we need native fuzzing since AFL keeps regressing everytime a new version of LLVM comes out
- for the longest time we haven't had a strong I/O story, now we're finally working on it
The time for paving the road for a new generation of programmers will come (it's in the ZSF mission statement btw), but first we need to finish the plumbing.
> Maybe, or maybe the fact that Zig is a small independent project with limited resources has also something to do with it
Or, maybe it's this kind of redirection and evidence of a victim complex. Part of the reason that there's a patina of anti-Rust sentiment includes the dismissive attitude and swipes you, a the VP of Community at the Zig Software Foundation, take towards Rust and Rust developers by writing about topics you aren't involved in and don't have a solid grasp of.
> infamously declared zig was "a massive step back for the industry"
> [Golang] "not memory safe"
Both of these are entirely fair assessments, not "attacks". Golang really does have memory safety issues with concurrent code, and a memory-unsafe language like Zig is a step back even compared to Java/C#, let alone Rust.
It's an entirely fair assessment within a framework of supremacism. "My language is the best. People who don't use it need to learn it. If they don't, they're bad programmers, maybe even bad people." It's a ugly spirit that no one is honest enough to admit to. But it's there. A few month ago, I saw a supposedly nice Rust leader calling SQLite "a terrible example of anything other than what you can accomplish when you pour enormous resources into a single C library."
The end result is that Rust's leaders either avoid interacting with other languages, or engage in flamewars. I think it's a big reason why Java, the most popular and successful memory safe language in the world, has little-to-no formal contacts with the Rust team.
There are a couple things about that take, that many would say deserves push back on: (1) Rust supremacism has been aimed at many other languages, not just Zig in particular. It's been a wide spray. (2) Many would say that Zig's leadership has done similar to what you are saying about Rust. Very clear examples have been the relentless unleashing on Vlang and its creator, and to a lesser extent on C3.
What might be the better critique about this, is that any programming language's leadership should not be engaging in that kind of bad behavior. And any ill words coming from them about another language, should always be taken with a grain of salt and seen as likely bias.
“Zig not being memory safe” is what's being called “a massive setback for the industry”.
Maybe you can make a hierarchy between technical criticism like this and the fact that Go isn't technically memory-safe[1], with Loris' abusive behavior of calling Rust maintainers names like “wankers”…
[1]: which is a criticism mostly coming from the Java crowd, by the way, not Rust, like the criticism of the simplistic garbage collection management in Go
It's true. Or rather, it's the emergent behavior of the community. Other languages typically don’t openly say, in writing:
> Then [Anti Rust person] should have been perma-banned long ago [on an open forum]. Until this is done, we'll have to warn people about engaging with him…
You can hate kristoff, ignore him or attack his arguments. You can also love a piece of software and treat it as sacred. But other people should not be subjected to that love nor should they be canceled on account of it. Flag it or downvote. Beyond that, it's outside of our control.
I do agree though that kristoff should focus on Zig and not indulge in provoking old enemies. His valid points— deferring premature documentation for newbies until concepts are ironed out— are being lost in programming language holy wars.
> Other languages typically don’t openly say, in writing:
I'm no language though…
> You can hate kristoff, ignore him or attack his arguments. You can also love a piece of software and treat it as sacred.
It's not about “love” or “being sacred” or even about Rust or Zig, it is about behaving in society. Most successful communities at some point meet toxic people who want to start holly wars and insult people. Successful communities are the one who ban those people, or at least coerce them into behaving through social pressure.
When you don't do that, you end up with bullies like Loris occupying prominent positions, and that's very bad for the community because it attracts people like that.
It has nothing to do with programming languages at all.
And sorry to say that bluntly, your discourse about “supremacism” “love” or “sacred” sounds very immature: programming languages are tools and engineering projects, not icons that should be worshipped or hated, they all have their strong points and warts (and god knows Rust has its share of annoyances…). Don't get dragged in holy wars by cult leaders like Loris.
This Zig victim complex, smells of clear hypocrisy, as can be easily seen by their swipes and harassment of other programming languages, like V (Vlang).
It reflects poorly on any leadership engaging in that kind of bad and unprofessional behavior, and it eventually backfires on any project or person. People eventually notice it and figure out the foul things that have been or is being done, then demand accountability or walk away from the toxicity.
I don't know hat makes you think I'm talking about disagreement, but that's not what I'm talking about, if one cannot help insulting people on a forum, then what they deserve is a ban. First a temporary one, then if they still can't behave then a permanent one.
Loris is a bully, that's the problem, not his opinions.
I just wanted to clarify that I point this out to say that there was a real opportunity in this thread to try to push back on the language wars perception. To me, good community management would be taking the opportunity to say:
* Sorry you feel that way, we try not to foster an inclusive environment that avoids language flamewars and negativity towards other languages
* Some specific examples of policies that are enacted in community spaces towards that end (e.g. some large programming language discord servers have specific rules against low effort language bashing content and memes)
* Take the opportunity to link back to positive things that the Zig team has said about Rust and places where folks have recommended it.
Instead, we got a shallow dismissal and redirection, which unfortunately starts to look like a pattern, especially when coming from a person who's in a leadership position in the community being discussed.
> […] Zig was still using the bootstrap compiler written in C++ that would not free memory […]
That sounds strange. Modern C++ requires very little manual memory management, at least when you're writing something high-level like a compiler. C++11 had been out for years when development on Zig started. Were they writing C++ old-school as C-with-classes and malloc() everywhere? Why not use a more appropriate language for the first prototype of a compiler for a brand new language?
IIRC, it was a performance thing, and it's not an uncommon pattern in CLI tools. Freeing memory can actually cost you performance, so why not just let the OS clean up for you at exit(2)?
Why would you care about these kinds of micro-optimizations at that stage of development, when you don't even know what exactly you need to build? We're not talking about serious algorithmic improvements like turning O(n²) into O(n) here.
> Freeing memory can actually cost you performance, so why not just let the OS clean up for you at exit(2)?
Because a compiler is not some simple CLI tool with a fixed upper bound on resource consumption.
> Why would you care about these kinds of micro-optimizations
it turns out that compiler speed is bound by a bunch of things, and it's death by a thousand cuts. If you have a slow compiler, and it takes forever to compile your compiler, your language becomes scelerotic, no one wants to make changes, and your language gets stuck in shitty choices.
> Because a compiler is not some simple CLI tool with a fixed upper bound on resource consumption
yes. thats right. a compiler is complex and should use several different allocation strategies for different parts. if your language steers you towards using malloc for everything then your compiler (assuming it's bootstrapped) will suffer, because sometimes there are better choices than malloc.
You're losing sight of the full picture: This "optimization" was such a hindrance that they had to rewrite the compiler before they could work on the ecosystem of their new language. From kristoff_it's comment [1]:
> When I first joined the Zig project, Zig was still using the bootstrap compiler written in C++ that would not free memory (it took more than 4GB to compile the Zig compiler). Some people at the time were asking us to prioritize work on the package manager but Andrew rightfully wanted to prioritize rewriting the compiler instead. In hindsight this was the obviously right decision: a package manager implies that one can very easily add an order of magnitude more code to their project, stressing the performance of the compiler. If we had not prioritized core infrastructure over giving people what they wanted faster, today we would have people complaining that adding a single dependency to their project makes the build impossible to complete.
> they had to rewrite the compiler before they could work on the ecosystem of their new language.
I think you may have missed that the intention was always to rewrite the compiler to become self hosted. Improving the C++ implementation any more would've been pointless optimization.
no. a global arena is not the right solution for every project. but believe it or not, the zig compiler does use arenas as one of its strategies (just not global arenas), so yes, access to that strategy for performance improvement is still important and absolutely being used in the zig compiler today.
Maybe, or maybe the fact that Zig is a small independent project with limited resources has also something to do with it, and this kind of shaming says less about Zig than you'd think.
When I first joined the Zig project, Zig was still using the bootstrap compiler written in C++ that would not free memory (it took more than 4GB to compile the Zig compiler). Some people at the time were asking us to prioritize work on the package manager but Andrew rightfully wanted to prioritize rewriting the compiler instead. In hindsight this was the obviously right decision: a package manager implies that one can very easily add an order of magnitude more code to their project, stressing the performance of the compiler. If we had not prioritized core infrastructure over giving people what they wanted faster, today we would have people complaining that adding a single dependency to their project makes the build impossible to complete.
The Zig project has a huge scope and we are a small independent organization. This makes us extremely nimble and efficient, but it does mean that we need to do things in the order that makes the most sense for the project, not for what the public wants.
The fact that we develop in the open doesn't mean that the language is ready yet.
People that already have the required domain knowledge (and who have a tolerance for breaking changes) will have the opportunity to be early adopters if they wish to do so, others will have to wait for Zig to become more mature. And we do make this clear in releases and all forms of public communication.
We have gone a long way since the bootstrap compiler days, but we are still missing key infrastructure:
- we have a x86_64 custom backend but aarch64 is not complete yet - incremental compilation is showing that we can get instant rebuilds of large projects, but it has missing features and it doesn't work on all platforms yet - we need native fuzzing since AFL keeps regressing everytime a new version of LLVM comes out - for the longest time we haven't had a strong I/O story, now we're finally working on it
The time for paving the road for a new generation of programmers will come (it's in the ZSF mission statement btw), but first we need to finish the plumbing.