oh ok I understand it better, I guess there are many school of thought on that regard, I think it’s the berkley vs Mit approach if i recall correctly, where one prefer to release things “finished” and go from there, and the other is more “Ship as soon as possible and use that to guide the rest”. I can see the frustration, and agree to some extent, makes more sense the way you put it, I hope they will improve in the future, and while I can understand your pov, I personally don’t mind their approach, but can see how it could be improve 
2 Likes
Hello,
I didn’t engage here much because I really don’t care about Zig being LLM friendly.
However since everybody is giving a piece of his mind… I want to share my experience:
-
At work the choice was taken for and against me. I’m very successful with it and I feel no achievement or pride for it. I see people getting crazy over skills and what not… I just talk to the bot and it does what I need. It kills all the interest I have for work. But hey, be it. I’m a ‘resource’, my company doesn’t translate my feelings into money or debt.
-
System programming is not something my company wants to hear about. So if I want to practice, it needs to be a personal project. But when I checkout from work, I’m absolutely fed up by AI and there is no way I spin an agent and pay a 10-200 bucks a night to work on my OSS… which in itself deprives me from the deep internalization I make when I code.
Some hard truth: On top of being obedient and complacent, AI codes much better and faster than the vast majority the people in my company.
Some cheering up observations:
- when I compare my control over my personal project and what I do at work, it’s like day and night.
- “but you could have done it in a week instead of 3 month”. Not in a week, learning the concepts and the field I was getting in to steer it would have taken time and it would have costed me a ridiculous amount of money. I would not get squat to what happens inside and I would most likely be in a dead end with a lousy POC.
- Time to market is not everything. I’m coming in a field where some software is approximately already in place since 30 years.
My “bet”
Innovation is quickly plummeting. When nobody cares about something, it stagnates. It’s like the “Google’s first result” focus. Everybody does the same thing. At that point maybe people start valuing craftsmanship again?
About bread
I always did the same analogy with portrait, plein-air and camera… Some people just want to do things themselves or express something. Delegating it is pointless in that case.
15 Likes
I feel like I’ve already said everything I wanted to but I’d like to say few extra words about this specific point, because I’m not sure if you (Zig team) are aware enough. I agree 100% that everything that helps people also helps LLMs. But LLMs are having exact same difficulties as we all do:
- having to invent new names because there’s some var with the same name already.
- having to rename something to
_just because we are trying something really quick and it’s not used (temporarily) - having to change
vartoconst, because it’s not mutated anymore (again, we are trying out something) - having to fight all those absolutely diabolical
@as(xx)conversions, every time I want to do some basic math - missing
.{}because we don’t have var-args
All of this has been already said, many times, not just from me. Other languages have their own warts, I get it, and if this works great for writing compilers (usual reaction to this kind of feedback), then maybe Zig will become really good for writing compilers, but you also say Zig is general-purpose. And I think that means you should be willing to listen for feedback from people writing general-purpose, non-compiler code.
I also agree with what @lalinsky said - 0.16 was obviously a lot of work but it was unfinished, and 0.17 is going to be unfinished again (from my point of view, none of the features introduced 0.16 are finished on master). Net effect is that I had to fix all the things you broke along the way, and it was (in my case) for no benefit.
Note again, that this is not a hate - I am thankful for all what Zig team is doing, and I have huge respect for all of you. It’s just my feedback, from my experience, after using Zig every day for ~3 years.
6 Likes
They sure have, and I find that discussions like this often lose focus when people give into the temptation to go over their own list of pet features they want added or removed. FWIW, apart from verbose type conversions, I don’t agree with anything in that list – certainly not the lack of var-args, which were once part of Zig and were rightly removed to simplify the language. The lack of shadowing and the rules around var use are exactly the kind of bug prevention features that are friction for some humans but not a problem at all for LLMs.
The separate point you made about release cadence and breakage is totally valid. Supporting 0.16 in my own project was a ~10k line change I made over months of work, completely hand-coded, so I felt the pain That said, 0.16 was a beast of a release, and balancing ambition with pragmatism when working on releases is obviously an unsolved problem.
6 Likes
I agree, although I’m OK with the breakage. Certainly because my own project is exploratory and having a mandate to break things just gives you incredible freedom to improve the thing…
All of these things have been discussed extensively and are considered features. The first 3 bullet points especially have caught many bugs in my own software. The only weak point are casts, which are due some fine-tuning (see https://codeberg.org/ziglang/zig/issues/35197 wrt peer type resolution changes), and that’s well-known.
I and pretty much all other core team members maintain non-compiler projects, and in any case compilers are not that different from normal applications if not maybe for the fact that they memory management needs that are pretty simple… until you decide to implement incremental compilation.
As for 0.16.0, yes it was a messy release. I skipped it essentially for Zine (my static site generator) because of all the translate-c regressions.
Zig releases are mainly meant to be in sync with LLVM (hence why they generally happen every 6 months) so that distro maintainers won’t boot Zig out of the package manager when they upgrade their version of LLVM. Occasionally the release is cut with unfinished work because a new version of LLVM has come out and we can’t wait too long before releasing as well (if we want to keep being nice to distro maintainers). Sometimes release dates have slipped as well, when a load-bearing feature was being reworked and it was not back to passing tests.
I understand wanting for Zig to be more mature and for releases to be “real” releases, but that’s not where we’re at, and we never made secret of it.
I think that what you guys are trying to say is that you wish that Zig were more production-ready because LLMs are coming and you’re worried that it will become irrelevant before it’s even complete. I’ve already replied to that at the beginning of the thread, but to restate my thinking using different words: we’re not dumb nor blind and we have our own way of navigating the shifts in the field. If you don’t trust us to be able to that well-enough, then we can have a direct discussion about that point (in a different thread), because discussing it by proxy is at the very least inefficient. Arguing for example that LLMs have issues with shadowing rules or with const/var is pretty much the opposite of what’s true.
11 Likes
You misunderstood the point of the quoted post. I felt ashamed, because of the language of the release notes. There was absolutely no reason to take a dig at libxev, for having an issue with some kqueue use case, when std.Io.Kqueue didn’t even compile. It sounds extremely childish to me. And this keeps repeating in messages coming from the Zig team. Combined with the unfinished features, it gives Zig a bad image. I also specifically said in the post, that I don’t want to hurry, Zig can keep experimenting and exploring, that is not an issue. All I want is a more serious approach to the product. I’d really love if Zig aligned itself with LLVM, as you said, and only merged features once they are finished, or specifically marked something as experimental, without forcing everybody to migrate to it.
5 Likes
I will be the first to declare that I love these features for exactly that reason: they catch real bugs. But I also think they introduce unnecessary friction while you are developing, trying ideas, commenting out some code, etc. And I think the fact that the Zig team refuses to acknowledge that this friction does exist, causes a negative view of the language development process among many.
Every time these points are raised, the answer is mostly “but the friction is intended because it catches bugs” and completely ignores the valid cases in which the friction is unwarranted.
I would prefer to see an answer where the team says “yes, this is friction, it is a PITA while developing, but we think the problems it avoids for production code warrant having the friction always present”. What it feels like today is, people raise reasonable concerns, which are just ignored.
I love Zig, and I would still rather develop with it than with any other language. As always, thank you to Andrew and the whole team for a fantastic language.
2 Likes
I can’t provide proof for this, so accept my apologies, but I do feel like this is the messaging that I’ve read most frequently, especially around the unused variable compile error. Maybe the way it is written is such that it feels hard to hear that message? When the core team says “this friction is good” or “this friction is useful”, I’d suggest trying to take them to mean what you wrote here, rather than “git gud”
2 Likes
There’s plenty of footage on record of me hitting unused variable compile errors and what not. Nobody in the core team is (or thinks they are) Code Jesus.
3 Likes
The main usability problem with those errors is that they hide the real error by being trigerred before Sema. They should be treated like compileLog and only be reported if no other error is found.
For the question about gouvernance, I think that the “contributor pipeline” is totally clogged. Andrew said one at some point “you can influence the roadmap by sending PRs”. I don’t think that’s true anymore. Browsing the commit history and it’s 99% the core team. I understand it’s hard from the core team pov, but some parts of std should be delegated more. eg Frank Dennis does a lot of work for crypto and it works well.
Could someone have the same role for Io? Worst case it can be changed after a release if Andrew doesn’t lile the direction taken?
6 Likes
These are compelling arguments, I’m in agreement with your first point (although I haven’t discussed with the rest of the core team so there might be some other implication that I’m missing). The “build the executable even in the presence of errors” proposal would address this in any case (I don’t remember the issue number sorry), but it might make sense to revisit this decision independently in case that proposal doesn’t end up being implemented.
As for the latter, we’re working on it. We’ll be sure to post about it as soon as anything changes, but for now I have nothing useful to report.
5 Likes
I understand how it can be useful. What I don’t understand is why it cannot be turned off, or why is it an error and not a warning. There’s a lot of value in static analysis but most languages do that separately, and not as part of compilation.
And to be clear, after 3 ys I already know what you will answer (including the argument that compiler is basically built around this and it cannot be changed, which frankly sounds like weird decision), but unlike other Zig differences, these 3 are as painful as they were when I have started with Zig.
5 Likes
What I don’t understand is why it cannot be turned off, or why is it an error and not a warning
Favor reading code over writing code. (c) Zig zen
But I wonder how “build the executable even in the presence of errors” will play (is it accepted proposal at all?) with Zig zen “Compile errors are better than runtime crashes.”
“This too shall pass.”
– Persian poem
Predicting the future of our industry seems like a pretty hard task to me.
That said, if we are trying to do it anyway, it’s probably worth considering non-technical factors.
Would your traveling habits change if plane ticket prices were reduced by 10? What about multiplied by 10? We all know that LLMs are heavily subsidized. How much is difficult to know. What is the real cost of an LLM query? How will your habits change if the price is x10? The (great) bread analogy only holds if the industrial bread is cheaper.
Let’s say your company replaces all its engineers with ChatGPT agents. Is it a good idea to rent your business? What prevents OpenAI from cloning it?
Can an organization even function if your employees don’t feel responsible for the work they produce?
What about skill atrophy? Bread is pretty simple. Engineers working on industrial bread machines don’t need to be bakers. But it looks like LLMs work best when piloted by an expert.
What about regulatory capture? What about public pushback? Will LLMs stay legal?
Can a wasteful technology like LLMs exist in a sustainable world?
Local open-weight model, you say? I agree; it seems like a good idea. But why are they free? Will they continue to be free in the future? Who will update them?
¯\_(ツ)_/¯
“Your future hasn’t been written yet. No one’s has.
Your future is whatever you make it. So make it a good one!”
– Doc Brown
P.S. I want the zig team to take all the time they need. What a beauty this language is starting to become!
8 Likes
I appreciate it that zelda-rageux posted his original French text as well. In contrast to alanza I don’t think the machine translation is bad, although I surely would have digested a handwritten English version with the same pleasure.
The content is all that matters; I happen to be in zelda-rageuxs age category (on the other side of the 5|6 prefix even), and all seems very recognisable to me. I like his thorough reasoning and completeness and am glad that, despite his initial hesitation, he decided to send the message.
It resulted in a very readable and interesting thread.
2 Likes
What an interesting read, this entire thread full of opinions and more than anything love for the zig language!
I hate that I’m slowly moving my hobby projects away from zig, the constant breaking changes became an insurmountable mountain with my very limited time. The breaking changes often come without a direct do this instead hint making the process painful, once the language is stable I will relearn the std library and the final version of zig once instead of doing it every so often.
I wish I had a stable and superior language today. Yet I have to acknowledge that making zig even better is not a bad investment. So I am back to making do with what I have.
I do not buy the premise that zig can miss the train. If anything I feel the rise of LLM porting means the train becomes more hype and less fact. When zig is ready my work can easily be ported back to zig preserving the design choices I’ve meticulously crafted.
Edit: I forgot to say this: Let the team cook!
1 Like
ZLS supports fixing unused args and wrong const/var definitions automatically, this took out 95% of the friction for me immediately.
I’d argue that anything that can be fixed with editor tooling should be, and otherwise the errors prevent real mistakes and obfuscations from slipping through.
1 Like