> It doesn’t matter that the language you use is memory-safe, if you didn’t design for correctness or have no process that will eventually lead you to fixing all bugs.
After many years in the business I have come to a more pragmatic view. There is no meaningful way of distinguishing features from bugs. It doesn't matter that work tracking software usually does.
Once you realize that the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features", then you also accept that you will never be done.
If you have a bug to fix to weigh against a feature to add, which do you pick? The only correct answer is "The one that provides most value". And again we see that it's very possible - even likely - that fixing the last bug will _never_ be as important as adding more features.
I know this is probably not what the author meant. First of all "having a process" doesn't mean completing the process. Second of all, you can categorize bugs as being of a specific kind (The linked article under [fixing all bugs] actually only talks about failing asserts).
>Once you realize that the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features", then you also accept that you will never be done.
This doesn't make sense at all.
Your email software mangles my email. Or your media player randomly skips. That's a bug. No big philosophy needs to be hidden behind it. That your media player doesn't have the shuffle feature is not a bug. It's just an item on a wishlist.
>If you have a bug to fix to weigh against a feature to add, which do you pick?
Depends on the seriousness of the bug. If your disk backup software corrupts backups, I'd fix that, I wouldn't go add schedulled backups or encryption first.
If what you meant to say is that bugs and features are both items to prioritize when deciding work, sure. But they're not the same thing and are not hard to tell apart, so the metaphor doesn't work.
Grandparent is onto something. You can't define correctness without a spec. And since most business-oriented software, which most of us work with, isn't made against a comprehensive spec, you can argue that anything falling outside it is either a bug or a feature. 'If your disk backup software corrupts backups' has behind it a clean definition that's (pretty) unambiguous and you don't care about, since it's already outsourced to some cloud solution. But 'User finds it easy to buy more stuff' does not.
Also, mandatory Sussman reference [0], where he talks about correctness not being that important and gives Google as example, that just needs to be close enough and not disastrously incorrect + interesting stuff around engineers confusing brittleness with correctness.
There are things that are clearly bugs and clearly features. And a lot of things that are somewhere in between. It’s not black or white and as such perhaps not worth categorizing?
Especially with dramatic processes like ”always fix all bugs before implementing any feature”.
>There are things that are clearly bugs and clearly features. And a lot of things that are somewhere in between. It’s not black or white and as such perhaps not worth categorizing?
I appreciate the exercise of taking a step back and looking at the abstractions built, really I do, sometimes people take a liking to certain bugs, sometimes people despise features as if they were bugs, but this feels a bit of a Loki's wager situation: https://en.wikipedia.org/wiki/Loki's_wager
At the very end of things, bugs and features are just things the software "does", but I reckon it's worth it to sit back and think about the intentional and non-intentional result of the application of a design.
My read was they were not saying they’re actually, literally, the same, but for the purposes of prioritization there’s no point in differentiating feature from bug when you use the same “how does this impact my products value to users” as the deciding factor for what gets scoped.
It’s an interesting insight but I’m also not sure it’s valuable in practice. Sort of like “we’re just bags of chemicals that tricked rocks into thinking”.
When you're trying to prioritize work, bugs and features are the same - they're both demands for developer time. I don't think they were saying anything more than that.
You want to say that they're not the same kind of work? True. And yet, when you're allocating work, that doesn't particularly matter.
Perhaps you have framed this overly strongly, but I think I get what you mean.
I have worked in companies where "X is not complete" would be logged as a bug. Even beyond that, non-completeness often leads to behaviors, especially as users bed in around non-complete interfaces, that are obviously bugs, crashes and the like.
If software represents a theory, any expansion in that theory (new features) will tend to lead to non-completeness, which will tend to lead to bugs. This is almost a mathematical certainty.
Engineering around this implies restating your theory, and thus performing partial or total rewrites of your software, quite regularly. It's not as crazy an idea as it sounds, I'm sure there are architectural patterns that make this manageable.
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies."
> There is no meaningful way of distinguishing features from bugs.
Especially when you implement it exactly as directed by a project manager. Everyone forgets why it was done the way it was done, and then the same project manager asks for it to be "fixed" despite it being the way they wanted it in your original ticket.
> I have worked in companies where "X is not complete" would be logged as a bug
I've come to realize it's all about perspective. Something from the engineering stand point may not be a bug because there's nothing to fix.
But the user might be having a bad experience because of that so it must be a bug.
In the end, the user's perspective might be the less-wrong one.
Some times there is, and in many cases there is not. Distinguishing a feature from a bug requires having some kind of spec. In some cases you can have obvious sign the behaviour is unintended/not desired, but in other cases it's not so easy.
For example a customer reports a bug, your program can't print. Oh, you say, we never even had that feature! Please post again, as a feature request.
Customer mumbles and requests the same thing as a feature request, not a bug report. They never understood what the difference was though. They couldn't print. Program bad.
Now you implement the printing feature. There is an infinity of things to handle there. You add the 99.9% case which is basically regular printers, perhaps normal paper sizes. You however don't throw in things like document splitting (sending different pages to different devices based on capability). You have to stop somewhere. None of this is specified, however. None of the limitations are communicated to users. But you added the feature - in some sense.
Then a customer with a 1970's pen plotter files a bug report that your new feature doesn't work on his device. Will you fix his bug? He's the only one on the planet with the problem. Is it a bug or a new feature? To him it's _clearly_ a bug. To you it would _clearly_ be a new feature to support pen plotting. You could argue the semantics of whether this is a bug or a feature until the sun goes down and it doesn't really matter. Either the fixed bug/added feature has enough value to be done, or it doesn't.
A key takeaway here: this isn't merely something that appears in the perspective of the user vs the developer. The argument about whether you actually have a "Bug" because you stopped short of implementing every kind of printing known to man is one you could have with your PM too. He likely didn't even consider that. But does that make it not a bug?
There is a pretty clear and important difference between a program that does something wrong, and a program that just doesn't do something somebody wants.
"You don't support printing", "pressing the print button doesn't print", "pressing the print button crashes the computer" and "pressing the print button lets an attacker get root access to the system" are all different and it makes sense to distinguish them. (The first is a missing feature, the second and third are different kinds of bugs, the last is a special kind of bug we call a security vulnerability.)
That distinction might not be useful to end-users, but it's useful for the people building the system! If you want to care about quality, committing to a strategy like "we will not add features before we fix known bugs" is totally clear, reasonable and effective. There might be some frontier of issues where it's hard to make a distinction, but that just means there are subtle edge-cases, not that the whole concept is undefined. A lot of perfectly cromulent concepts have edge-cases! You can just decide those on a case-by-case basis; if it's actually so close as to be legitimately confusing—it's not just feigned ignorance or political posturing—which side you choose probably doesn't have much of an effect.
This does depend on having a reasonably clear idea of what you're building, but that "reasonably clear idea" does not have to be anywhere near the detail of a "full spec", much less anything formalized. To me, that seems like a baseline you'd need to build quality software at all, and hardly an unreasonable thing to expect. And if most teams can't manage, well, it's just another explanation for why most software is crap.
> There is a pretty clear and important difference between a program that does something wrong, and a program that just doesn't do something somebody wants.
Your argument hinges on all parties agreeing on what "wrong" means. Take a step back and consider that parties do not agree on a common definition of "wrong." Does "wrong" mean a gap between the spec and the implementation or a gap between a reasonable user's expectation and the implementation? If one party assert that it is clearly the former and the other party asserts it is clearly the latter, does that make the situation more clear or less clear?
Just because you can't get everyone to agree does not mean that the concept is not well-defined or clear. People can and do disagree over almost anything. That could just mean that one side is wrong and the other side is right, even if it is difficult to determine which is which... or simply difficult to navigate the underlying politics regardless.
Besides, in your example, either kind of gap could be a bug or a missing feature. It's a totally orthogonal question.
There are some really obvious things that are definitely bugs. If login doesn’t work if your email address contains the letter “e” when the expectation is all valid email addresses should work, then that is a bug. It isn’t “indistinguishable from a feature”. If clicking a button in your accounting software consumes all the RAM on your computer and causes it to crash, then there is no universe or agreed upon definition that would consider that a feature instead of a bug.
>Your argument hinges on all parties agreeing on what "wrong" means
No, it just hinges on common sense. "All parties" are never gonna agree on everything.
There will always be customers that demand whatever and treats its lack as a bug. Doesn't make it a bug anymore than me asking for a free glass of wine with my meal and not being given any is "injustice" - when the restaurant never promised any.
An unuseful-in-99%-of-cases definition of bug would be "any behavior that is not in the spec is a bug". But that would mean not shipping fast and breaking things. And having a spec.
> For example a customer reports a bug, your program can't print. Oh, you say, we never even had that feature! Please post again, as a feature request.
As a sidenote, I dislike it when a vendor makes me care whether something is a bug report, feature request, or support query prior to filing it. I'm willing to make an assessment on whether the query is of a public or private (if I'm unwilling to publish publicly, sensitive customer info, potential for vuln et c.) nature but beyond that I don't want to spend any time arguing about classification.
>Some times there is, and in many cases there is not. Distinguishing a feature from a bug requires having some kind of spec. In some cases you can have obvious sign the behaviour is unintended/not desired, but in other cases it's not so easy. For example a customer reports a bug, your program can't print. Oh, you say, we never even had that feature! Please post again, as a feature request.Customer mumbles and requests the same thing as a feature request, not a bug report. They never understood what the difference was though. They couldn't print. Program bad.
Any software has a spec. It might not be publicly written, but you have in mind what you build and which features it supports. And software that's sold has lists of features, presentation pages, and trials for people to see its features.
If some random user can't tell a bug from a feature, that's on them.
You must use some very small software if what it does can be held in the mind alone. Try working on something with hundreds of thousands to millions of lines of code. Have it evolve over 5 different PMs. Have it serve enterprise customers. Even something simple like
* Supports FooBaz
Now means, supports what feature set of FooBaz, what particular versions of FooBaz, does it support the fork FooBar that have the market quickly migrated to, what about the bugs in FooBaz that only show up when using your program.
Users are dumber than you think, and when they pay you a lot it's never on them.
Not even a development team can (or should!) be able to agree on whether something is a bug. Just because there is never a complete spec. It’s a mental state of the team. Or expectations among stakeholders.
A bug is a feature that does what the code says it should do, not what the requirements say it should do (or shouldn't in the case of most bugs). When you understand that there's no difference between a bug and a feature in the code. They're both just code.
It's a correct statement, but when you're talking about memory safe languages it's true that memory safety helps you avoid writing code that doesn't do what you were expecting, so I'd still suggest memory safety matters for reducing the number of bugs.
I read it as an argument from the end user’s perspective. Kind of like this:
- trying to do X, getting software error: bug
- wishing the software did Y, even though it’s not implemented: bug
Indeed there are people who think like that, but usually they are people like my grandparents, whose level of software understanding boils down to “the Desktop is where I play Solitaire” and “Internet Explorer is the literal internet”.
That's the simple version of it yes. I outlined a more complex version of it in a parallel answer. In short: lacking a complete specification of what to do, it's often impossible even within software teams to tell whether something is a bug.
And you never have a complete specification of what to do.
And a developer doesn't have to give the same semantics as the user, anymore than a medical equipment manufactured needs to consider its products based on what each random patient wants and what misconceptions or urban legends they believe.
A bug means that there is a feature, but it's not behaving as was specified. (Or expected, or as it used to ... but clearly a difference to something, not to nothing)
It doesn't matter whether to the end user that's indistinguishable. It is for us, the professionals.
It's the same as with any other profession and domain-knowledge.
If my heater doesn't work but it used to work, that's a bug, a regression.
If it doesn't integrate with my smart home, that's not a bug. It was never a feature to begin with.
> If you have a bug to fix to weigh against a feature to add, which do you pick? The only correct answer is "The one that provides most value".
I agree.
> And again we see that it's very possible - even likely - that fixing the last bug will _never_ be as important as adding more features.
Depends entirely on the project and the revenue stream. I've open sourced code which I consider done. It does what it should do and I won't any more features to it.
I will however fix bugs within the existing functionalities.
When a program clearly deviates from its spec, would you be okay with calling that a "bug"?
There's always a gray area of what's intended by the spec, but a program can absolutely and blatantly deviate from the letter of the spec, and they often do.
This distinction seems worthwhile to me, because it means that something someone already relies on does not work (anymore), even though reasonable people would agree that, according to the spec, it should.
Absolutely would. But if we can categorize 1/3 of defects as ”bugs” 1/3 as ”missing or incomplete functionality” then there is 1/3 in the middle which we can’t decide. So the dichotomy is kind of weird, and making ”rules” and processes about this categorization is probably not worthwhile.
At least not worthwile for the purpose you have in mind. Okay, now I understand better what you mean, something like: for some purposes, there's not much to be gained by distinguishing between "bug" and "feature", one major reason being that there is no clear boundary between the two.
I first read your original comment in a much more absolute way (there is no distinction at all, and it never makes any sense anyway), which is quite easy to disagree with.
By "The one that provides most value", do you mean in the short or long term? Very often, in my experience, prioritizing so-called "quick wins" only quickly wins the codebase more tech debt, that puts the project on a sure path to development hell.
I imagine it's a difficult time to be a Zig developer.
In the near term, Bun choosing to switch from Zig to Rust specifically to fix all the memory errors seems to have done the Zig community some psychological damage.
But more significantly, in the medium term it looks likely that AI coding is going to overtake the industry before Zig gets properly established. And it is going to be very hard to justify choosing Zig for your sloppy-but-functional AI-written code - why open yourself up to memory unsafety on top of everything else? Further, the Zig community appears to value a hand-crafted, 'artisanal' approach to software development, which is the very antithesis of vibecoding.
I have no particular interest in Zig as a language but definitely feel some empathy here. The industry is changing in ways that many of us are struggling to process.
> I imagine it's a difficult time to be a Zig developer.
In some ways it always has been, the community was 'born' in the middle of the pandemic, then for a long time there was a constant influx of Rust zealots coming into threads about Zig to remark how immoral it is to use Zig, and now LLM shovel sellers are telling everybody that the only way forward is to become efficient at consuming tokens.
But it's actually not that bad.
The Zig community is growing pretty well, useful software is being written in Zig, and the advantages that Zig brings are still valid whether you hand-code or use LLMs (e.g. cross-compilation of C/C++ code).
This might be a very naive take on my part, but I don't think of vibecoding as a competitor to actual coding the same way I don't think of doing amphetamines (even if they make you more productive in the short term) as a competitor to being clean. I think it's a self-destructive behavior that is ultimately going to degrade your critical thinking skills, especially if you're a beginner. As with everything, the smarter your tools, the dumber you get. People often claim to acquire "higher level thinking" skills from it (as do meth users), but even if that's true, they are also currently teaching those skills to the very tools that try to replace them.
The question is why would you fare any better if you don't use it. I don't know how it will play out, but this much I know: I will never pay for AI music, because I can replicate it for free. I'm still buying music from real musicians (in fact tons more than ever before), because I can't. Similarly, I have contributed to many FOSS projects (both financially and in PRs), but will not (knowingly) do the same for the ones that are vibecoded. Whether that will amount to anything or is just a fart in the wind, we'll see.
the zig team says that in the future stabilizing the IR and providing an API will happen.
fwiw in the process of building this project the llms have never once written a memory safety error in the "lib" section (in the src section there was a lot of tripping over segfaults since memory mapping datatypes accessed by a dylib can get hairy)
I doubt this from my personal experience. Every week after a release, I see tweets complaining how AI wrote some depreciated code because Zig is making breaking changes every release. (They are valid in doing so, it's just not AI friendly yet)
Agreed unfortunately, if Zigs whole selling point is meant to be a "nicer C" (and a much nicer DX than Rust because no fighting the borrow checker etc) - does that really matter in a world where an LLM is writing the code? I am not going to be fighting the borrow checker, the LLM is.
And as always, the response you'll hear is: but AI sucks/hallucinates/could never replace me etc... Just look at the progress LLM'S have made in the past few years, and extrapolate that to the next 10 or 20 years. I don't see how Zig makes sense if this is the trajectory the industry is going.
Why would *any* programming language matter when LLMs can just directly output binaries from a sufficiently detailed spec ;)
And specifically, why would Rust be a better choice than C or Zig when the LLMs get good enough to just write memory safe code in unsafe languages (they are already pretty good at finding memory safety bugs).
IMHO for code generation, different things start to matter (like fast build times, while 'convenient highlevel abstractions' become less important).
Writing memory safe code in unsafe languages requires global reasoning, which LLMs are terrible at. The whole point of a type system or a borrow checker like Rust's is to thread the requirements for safety throughout the program syntax in a way that makes it possible to spot problems locally. That's why LLMs tend to be rather good at writing Rust.
> Writing memory safe code in unsafe languages requires global reasoning
If you learn how to use arena allocators and in general use modern techniques, you don't need global reasoning to write correct memory management code pretty much never.
If your code is a RAII and abstraction maze, then yes, you will probably need global reasoning, but that's not the case with Zig.
Writing anything safe code in any language that doesn't have that safety built in requires global reasoning. That's why LLMs aren't better at writing rm-rf/-safe code in Rust.
Why's everybody obsessed with the popularity contest?
Rust is a great language with some great killer features.
It does not need consistent propaganda preaching how it's a better choice than "insert other language".
Every system programmer is aware of Rust and it's pros. Doesn't mean it's a language that fits the use case, project, constraints and even preferences. It's not just about generating code, it's also about reading it and maintaining it.
Thus some people just prefer alternatives, be it C, C3, Odin, Zig, Jai or whatever else there is.
You said it yourself, it's selling point is "nicer C", so it's for people that don't want to write Rust or C++ but a nicer C.
> It does not need consistent propaganda preaching how it's a better choice than "insert other language".
Indeed. There is an irrational urge in some folks to become language-missionaries. Usually such folks have gained expertise in that specific language and want to protect and expand their turf. There is a wide-range of software usecases requiring a variety of tools and no one language fits all.
Amusing side-note. xai was all-in on rust for their ai-stack back in 2023. But now, spacex controlled xai is apparently coding ai in C - perhaps with the attitude that if a language is good enough to control rockets it is good for ai.
I think it's like this. People think differently. Someone finds a language that really fits the way they think, and it feels wonderful, and they feel like they've been let out of prison into this wonderful new freedom. And they, being empathetic humans, want other people to have the same experience, and they think that others will have the same experience if they just try this wonderful language. So they become language missionaries.
But what they miss is that other people think differently than them. Other people will feel let out of prison by a different language.
> In the near term, Bun choosing to switch from Zig to Rust specifically to fix all the memory errors seems to have done the Zig community some psychological damage.
Meanwhile, some projects are doing the opposite, like going from Rust to Zig, here's an example from a podcast I recently listened to: https://www.youtube.com/watch?v=XSXGf3oN2yU
I think Bun just got a lot of visibility because of the speed and scope of the migration, which both shook things up and I guess was good PR cause that made a lot of headlines.
I wish Roclang well but (as a regular listener to Feldman's podcast) I don't think we can draw many conclusions from this switch other than "Feldman has lots of opinions on lots of things".
You can replace the product and author name with Bun and the Bun author and the sentence also works, in the end all technical decisions are based on "opinions".
I mean, personally I just hope that at the end of the day everyone is as happy as the technologies in question will permit them to be. Either way I wouldn't say that Zig is done even after such prominent/loud news as the Bun rewrite.
Why do people even try to vibe-code stuff in low level languages?
You either care about non-functional aspects of your code, or you don't. Running your code through the shredder that destroys everything you don't test while insisting on writing it on a language that specifies non-functional properties... I don't have any other word, it's stupid.
I don't understand the idea behind Zig. What I have read sounded like "let's make a language like Rust, but not memory-safe", which doesn't make a lot of sense to me.
Even Rust has an unsafe subset. There's a meaningful question about how to make such an unsafe language as easy and comfortable to use as possible, and Zig is a decent answer to that particular question. The libraries Zig ships with are especially relevant here, rather than the core language per se: Rust's library facilities are outright terrible to write unsafe code with, because the usual requirements of safe code are assumed throughout and the whole point of unsafe code is to break those. (You can selectively relax those requirements, e.g. take &Cell<T> not &mut T, to allow for benign aliasing - but most stdlib code doesn't bother to!)
"Like unsafe Rust, but more convenient to use" is basically every imperative language around there, I still don't understand the specific niche that Zig intended to fill
I am not optimistic. When I look back in history, “worse is better” won every time. And vibecoding is the current epitome of “worse is better”. There are many places where code is a necessary evil, just a means to an end. And when the resulting software has never been particularly good anyway, then vibe-coded slop might just be good enough. Eventually, the economics will decide. There is a small chance that rising costs of LLM usage might save a segment or two from being devoured altogether.
1. Fixing memory errors wasn't the reason the project migrated to Zig, but a beef between the Bun maintainer not getting his own changes in the upstream compiler and the Bun's new employer focus on Rust.
2. You can write memory safe code in C (Redis, SQLite, OpenBSD, Git, etc), let alone in Zig which provides more tools to write memory safe code.
3. AI can write very good Zig already. This isn't 2024 anymore where "the LLM has seen lots of this language so will write better in this language" scenario existed. Will make you an example: I have worked in a very esoteric typescript fork called TS plus (providing among others fluent style apis for pipe-able functions) and even Opus 4.1 did well. Recently I have forked the Elm language and the LLM had no problem dealing with it, despite significant differences to the original Elm.
4. Zig's community uses Zig because it likes Zig and its tooling and doesn't like the constraints of other languages. Simple as that.
The truth is a bit of everything, bun being a messy codebase written primarily with "move fast and break things" in mind, cultural divergence between Bun and the Zig community, and also hiring issues. People maybe forgot but Jarred at some point caused a bunch of drama when he tweeted that working at Bun is not for people that value life/work balance, which went viral and caused an uproar. Must not have been super easy to hire from the Zig community after that, and in fact once Bun got acquired by Anthropic, it was pretty much Jarred and Claude doing all the work on the codebase. Pivoting to Rust is probably at least in part a way to reset the clock on those hiring interactions.
It is really inspiring to see other people passionate about programming. Really love the people building zig. Especially Andrew and Loris and some other people I saw in codeberg
Not all software is about usefulness. Especially in context of hacking, where software is a way of self expression and making something fun.
In enterprise usefulness is not the end goal either. Software can be very useful, but if no one is going to pay for it, it holds very little value for the business.
Damn this person's obviously is so bitter towards Rust... I wonder why he's so obsessed with it?
I mean, if they really care about software correctness, I wonder why take a very discutibile position and say that "safety doesn't matter if you don't use the correct process". Yeah, I mean, having some guardrails is better than none, right? If they really cared about correctness, they would really strive to put all the possible guardrails in place, wouldn't they? Maybe they are bitter because their fav language is not as popular as the other?
But there are so many languages, I wonder why picking on Rust specifically.
I don't get it. Are we reading the same article? This article is so generic that it reads like vacuous truth to me. But I don't see their bitterness towards Rust (or anything, really. It's just vacuous.) from it. Is this person a famous anti-rust'er or something?
It's like saying it doesn't matter if surgery is done another antiseptic conditions if the patient isn't also given a course of antibiotics during recovery.
It's not an argument against safe practices, it's an argument for amending one kind of safety with others.
I don't get how you dont't get. It links about memory safety (with a link towards an extremely biased article in Rust's favor) and a link to design to correctness (that leads to Zig project).
There is a lot to dislike about this paragraph:
It doesn’t matter that the language you use is memory-safe, if you didn’t design for correctness or have no process that will eventually lead you to fixing all bugs.
Hang on. If I want to prevent all bugs, shouldn't memory safe make your correctness much easier to achieve? And what is this about fixing all bugs? You mean proofs? The stuff that Zig doesn't aim to do?
And no, asserts don't fix all bugs, they just guarantee some of your invariants are held at best, used in test at worst.
If you sacrifice memory safety for correctness, that just means it's not correct. If safety is crucial, it must be safe under all inputs, and if there are data races.
It's a bit like saying, "Yeah, our system is safe, but if there are two threads racing or use after free somewhere, then all bets are off."
> It doesn’t matter that the language you use is memory-safe
> nobody can trick me into mistaking lesser stars for my true destination
The author seems to be in some level of denial around compile-time safety checks. They're right that runtime safety errors are an issue, but it feels wrong to discount compile time checkers when it can save a lot of yak shaving.
>It doesn’t matter that the language you use is memory-safe, if you didn’t design for correctness or have no process that will eventually lead you to fixing all bugs.
It's also worth noting that they linked a post about how memory safety is literally a matter of life and death, so it seems like their point is that memory safety is one class of bug, and a compiler guarantee about it doesn't equate to a guarantee of correct, bugless, unexploitable code.
Like, the linked author brought up that Khashoggi's wife's phone was hacked. Maybe that was due to a memory bug or some other kind of bug. Maybe the next journalist who gets hacked is a victim of a memory bug or some other kind of bug. But that linked post didn't take a holistic view of correctness, but went straight to, "Rust is safe. Rust saves lives." There's a logical error there that's being pointed out.
If you really want to save lives, you need to eliminate exploits. Not just do a victory lap because your compiler ostensibly eliminates one class of them. The compiler doesn't catch all bugs. The compiler isn't the only tool for catching bugs.
That's my reading of it, anyway. I think he has a point, and the Rust people do as well. I think it's wrong to portray him as bitter.
That is correct, this blog post is about understanding the priority of various subgoals and the ultimate goal (creating useful software). Memory-safety is important but overfitting on that subgoal, as I believe the memory-safety blog post is doing, won't make you create better software.
If Rust helps you get all the way to correctness, then great, but that blog post was insane.
> The compiler doesn't catch all bugs. The compiler isn't the only tool for catching bugs.
I acknowledged that in my prior comment. This person is letting perfect be the enemy of good, and I guarantee you that they aren't running their binaries through Valgrind and Ghidra to check the runtime safety after it's built.
Exploits like Heartbleed get shipped because people abdicate their responsibility to write safe software. Shackling developers to dynamic analysis tools is not any better of a solution than using a memory-safe language to start. Rust is shaving a calf to avoid the whole yak.
What 'all the comments'? There aren't many comments in this thread. You mean this: https://news.ycombinator.com/item?id=48432736 ? I flagged it too. I think the flag is quite justified.
oh I don't particularly care I'm just asking what is it about this article that is so worthy of being front page? I'm literally just calling out the content. I'm sorry for complaining.
It’s getting attention because the subtext of the article is the zig vs AI ideological battle going on (and zig vs Rust somewhat on the backburner)
Recent events AFAIU:
- bun (bought by big AI) switching to Rust
- zig team banning AI pull requests (because they want to review humans)
- The cloud industry buying all coding tooling companies (uv, vite, bun) but zig being unbuyable
If anybody from the zig core team is reading this: thank you and carry on the good work.
so im just getting caught up with zig is I have never really paid attention to it
so far I'm not really getting zig and I see they banned AI ? seems like that is just going to attract anti-AI user base...not sure if that was a wise decision.
also not really sure why anyone would migrate from Rust to Zig, it seems much less mature and unsure of the ROI there.
I think you will be surprised by how many developers do not have this same list of priorities (or in that order) when developing software.
I posted this link at the same time when I posted it to Lobsters (https://lobste.rs/s/g6lkw1/my_software_north_star) 3 days ago, but it didn't get on the front page. Seeing that the submission time has been reset, I imagine it was given a second chance by HN curators (it's a known process), but that doesn't mean free upvotes, it's just that some people resonate with the thinking.
It's bland and generic because it's a manifesto. Author (and HN submitter) is Loris Cro, aka @kristoff_it, VP of Community at Zig Software Foundation.
In his role, devising as set of general guidelines to use as compass when things (inevitably! and often!) get very very muddy and Right v. Wrong is hard to tell apart -- both objectively, and also from the point of view of being a community leader with ton of vested interest -- is essentially one half of his job. Other half is abide to said guidelines.
So @kristoff_it last week sat down, came up with three simple rules short enough he can print on a business card (or hang on his office wall or whatever), and posted them here to test if they make sense to the wider community.
TLDR: yes can seem bland / generic but within context it makes sense to me author needed to distill his ethics in a nutshell.
Agree, the claim "secure because Rust" is wrong. But "more secure than if it were written in an unsafe language" is probably going to be true most of the time.
Nah. You’re assuming that the developer has some experience. The false assurance that the magic of Rust will protect the developer from himself/herself will lead that young developer to make worse decisions. An experienced developer typically has discernment, and has learned, rather painfully, that he/she can make serious errors in any language.
> It doesn’t matter that the language you use is memory-safe, if you didn’t design for correctness or have no process that will eventually lead you to fixing all bugs.
After many years in the business I have come to a more pragmatic view. There is no meaningful way of distinguishing features from bugs. It doesn't matter that work tracking software usually does.
Once you realize that the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features", then you also accept that you will never be done.
If you have a bug to fix to weigh against a feature to add, which do you pick? The only correct answer is "The one that provides most value". And again we see that it's very possible - even likely - that fixing the last bug will _never_ be as important as adding more features.
I know this is probably not what the author meant. First of all "having a process" doesn't mean completing the process. Second of all, you can categorize bugs as being of a specific kind (The linked article under [fixing all bugs] actually only talks about failing asserts).
>Once you realize that the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features", then you also accept that you will never be done.
This doesn't make sense at all.
Your email software mangles my email. Or your media player randomly skips. That's a bug. No big philosophy needs to be hidden behind it. That your media player doesn't have the shuffle feature is not a bug. It's just an item on a wishlist.
>If you have a bug to fix to weigh against a feature to add, which do you pick?
Depends on the seriousness of the bug. If your disk backup software corrupts backups, I'd fix that, I wouldn't go add schedulled backups or encryption first.
If what you meant to say is that bugs and features are both items to prioritize when deciding work, sure. But they're not the same thing and are not hard to tell apart, so the metaphor doesn't work.
Grandparent is onto something. You can't define correctness without a spec. And since most business-oriented software, which most of us work with, isn't made against a comprehensive spec, you can argue that anything falling outside it is either a bug or a feature. 'If your disk backup software corrupts backups' has behind it a clean definition that's (pretty) unambiguous and you don't care about, since it's already outsourced to some cloud solution. But 'User finds it easy to buy more stuff' does not.
Also, mandatory Sussman reference [0], where he talks about correctness not being that important and gives Google as example, that just needs to be close enough and not disastrously incorrect + interesting stuff around engineers confusing brittleness with correctness.
[0] https://www.youtube.com/watch?v=HB5TrK7A4pI
There are things that are clearly bugs and clearly features. And a lot of things that are somewhere in between. It’s not black or white and as such perhaps not worth categorizing?
Especially with dramatic processes like ”always fix all bugs before implementing any feature”.
Claims from maintenance contracts in B2B depend on classifications like this. So, it is absolutely worth categorizing, for certain businesses.
>There are things that are clearly bugs and clearly features. And a lot of things that are somewhere in between. It’s not black or white and as such perhaps not worth categorizing?
I appreciate the exercise of taking a step back and looking at the abstractions built, really I do, sometimes people take a liking to certain bugs, sometimes people despise features as if they were bugs, but this feels a bit of a Loki's wager situation: https://en.wikipedia.org/wiki/Loki's_wager
At the very end of things, bugs and features are just things the software "does", but I reckon it's worth it to sit back and think about the intentional and non-intentional result of the application of a design.
My read was they were not saying they’re actually, literally, the same, but for the purposes of prioritization there’s no point in differentiating feature from bug when you use the same “how does this impact my products value to users” as the deciding factor for what gets scoped.
It’s an interesting insight but I’m also not sure it’s valuable in practice. Sort of like “we’re just bags of chemicals that tricked rocks into thinking”.
When you're trying to prioritize work, bugs and features are the same - they're both demands for developer time. I don't think they were saying anything more than that.
You want to say that they're not the same kind of work? True. And yet, when you're allocating work, that doesn't particularly matter.
Perhaps you have framed this overly strongly, but I think I get what you mean.
I have worked in companies where "X is not complete" would be logged as a bug. Even beyond that, non-completeness often leads to behaviors, especially as users bed in around non-complete interfaces, that are obviously bugs, crashes and the like.
If software represents a theory, any expansion in that theory (new features) will tend to lead to non-completeness, which will tend to lead to bugs. This is almost a mathematical certainty.
Engineering around this implies restating your theory, and thus performing partial or total rewrites of your software, quite regularly. It's not as crazy an idea as it sounds, I'm sure there are architectural patterns that make this manageable.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies."
-- C. A. R. Hoare
> There is no meaningful way of distinguishing features from bugs.
Especially when you implement it exactly as directed by a project manager. Everyone forgets why it was done the way it was done, and then the same project manager asks for it to be "fixed" despite it being the way they wanted it in your original ticket.
> I have worked in companies where "X is not complete" would be logged as a bug
I've come to realize it's all about perspective. Something from the engineering stand point may not be a bug because there's nothing to fix. But the user might be having a bad experience because of that so it must be a bug.
In the end, the user's perspective might be the less-wrong one.
what do you mean "there is no way to distinguish a feature from a bug"? of course there is
Some times there is, and in many cases there is not. Distinguishing a feature from a bug requires having some kind of spec. In some cases you can have obvious sign the behaviour is unintended/not desired, but in other cases it's not so easy.
For example a customer reports a bug, your program can't print. Oh, you say, we never even had that feature! Please post again, as a feature request.
Customer mumbles and requests the same thing as a feature request, not a bug report. They never understood what the difference was though. They couldn't print. Program bad.
Now you implement the printing feature. There is an infinity of things to handle there. You add the 99.9% case which is basically regular printers, perhaps normal paper sizes. You however don't throw in things like document splitting (sending different pages to different devices based on capability). You have to stop somewhere. None of this is specified, however. None of the limitations are communicated to users. But you added the feature - in some sense. Then a customer with a 1970's pen plotter files a bug report that your new feature doesn't work on his device. Will you fix his bug? He's the only one on the planet with the problem. Is it a bug or a new feature? To him it's _clearly_ a bug. To you it would _clearly_ be a new feature to support pen plotting. You could argue the semantics of whether this is a bug or a feature until the sun goes down and it doesn't really matter. Either the fixed bug/added feature has enough value to be done, or it doesn't.
A key takeaway here: this isn't merely something that appears in the perspective of the user vs the developer. The argument about whether you actually have a "Bug" because you stopped short of implementing every kind of printing known to man is one you could have with your PM too. He likely didn't even consider that. But does that make it not a bug?
There is a pretty clear and important difference between a program that does something wrong, and a program that just doesn't do something somebody wants.
"You don't support printing", "pressing the print button doesn't print", "pressing the print button crashes the computer" and "pressing the print button lets an attacker get root access to the system" are all different and it makes sense to distinguish them. (The first is a missing feature, the second and third are different kinds of bugs, the last is a special kind of bug we call a security vulnerability.)
That distinction might not be useful to end-users, but it's useful for the people building the system! If you want to care about quality, committing to a strategy like "we will not add features before we fix known bugs" is totally clear, reasonable and effective. There might be some frontier of issues where it's hard to make a distinction, but that just means there are subtle edge-cases, not that the whole concept is undefined. A lot of perfectly cromulent concepts have edge-cases! You can just decide those on a case-by-case basis; if it's actually so close as to be legitimately confusing—it's not just feigned ignorance or political posturing—which side you choose probably doesn't have much of an effect.
This does depend on having a reasonably clear idea of what you're building, but that "reasonably clear idea" does not have to be anywhere near the detail of a "full spec", much less anything formalized. To me, that seems like a baseline you'd need to build quality software at all, and hardly an unreasonable thing to expect. And if most teams can't manage, well, it's just another explanation for why most software is crap.
> There is a pretty clear and important difference between a program that does something wrong, and a program that just doesn't do something somebody wants.
Your argument hinges on all parties agreeing on what "wrong" means. Take a step back and consider that parties do not agree on a common definition of "wrong." Does "wrong" mean a gap between the spec and the implementation or a gap between a reasonable user's expectation and the implementation? If one party assert that it is clearly the former and the other party asserts it is clearly the latter, does that make the situation more clear or less clear?
Just because you can't get everyone to agree does not mean that the concept is not well-defined or clear. People can and do disagree over almost anything. That could just mean that one side is wrong and the other side is right, even if it is difficult to determine which is which... or simply difficult to navigate the underlying politics regardless.
Besides, in your example, either kind of gap could be a bug or a missing feature. It's a totally orthogonal question.
There are some really obvious things that are definitely bugs. If login doesn’t work if your email address contains the letter “e” when the expectation is all valid email addresses should work, then that is a bug. It isn’t “indistinguishable from a feature”. If clicking a button in your accounting software consumes all the RAM on your computer and causes it to crash, then there is no universe or agreed upon definition that would consider that a feature instead of a bug.
>If login doesn’t work if your email address contains the letter “e” when the expectation is all valid email addresses should work,
And what about the + symbol?
>Your argument hinges on all parties agreeing on what "wrong" means
No, it just hinges on common sense. "All parties" are never gonna agree on everything.
There will always be customers that demand whatever and treats its lack as a bug. Doesn't make it a bug anymore than me asking for a free glass of wine with my meal and not being given any is "injustice" - when the restaurant never promised any.
>No, it just hinges on common sense
Common sense doesn't exist in the business environment.
Sure it does. To a point, as all things. One could always have more, but it is what it is.
What party would desire to crash a program
An unuseful-in-99%-of-cases definition of bug would be "any behavior that is not in the spec is a bug". But that would mean not shipping fast and breaking things. And having a spec.
> For example a customer reports a bug, your program can't print. Oh, you say, we never even had that feature! Please post again, as a feature request.
As a sidenote, I dislike it when a vendor makes me care whether something is a bug report, feature request, or support query prior to filing it. I'm willing to make an assessment on whether the query is of a public or private (if I'm unwilling to publish publicly, sensitive customer info, potential for vuln et c.) nature but beyond that I don't want to spend any time arguing about classification.
>Some times there is, and in many cases there is not. Distinguishing a feature from a bug requires having some kind of spec. In some cases you can have obvious sign the behaviour is unintended/not desired, but in other cases it's not so easy. For example a customer reports a bug, your program can't print. Oh, you say, we never even had that feature! Please post again, as a feature request.Customer mumbles and requests the same thing as a feature request, not a bug report. They never understood what the difference was though. They couldn't print. Program bad.
Any software has a spec. It might not be publicly written, but you have in mind what you build and which features it supports. And software that's sold has lists of features, presentation pages, and trials for people to see its features.
If some random user can't tell a bug from a feature, that's on them.
You must use some very small software if what it does can be held in the mind alone. Try working on something with hundreds of thousands to millions of lines of code. Have it evolve over 5 different PMs. Have it serve enterprise customers. Even something simple like
* Supports FooBaz
Now means, supports what feature set of FooBaz, what particular versions of FooBaz, does it support the fork FooBar that have the market quickly migrated to, what about the bugs in FooBaz that only show up when using your program.
Users are dumber than you think, and when they pay you a lot it's never on them.
Not even a development team can (or should!) be able to agree on whether something is a bug. Just because there is never a complete spec. It’s a mental state of the team. Or expectations among stakeholders.
> Any software has a spec.
Note that the 'spec' you're referring to isn't the same thing as the 'spec' in your pulled quote. The Java spec tells us that the expression
refers to the value This is a bug in Java. It's not a bug in the implementation of the spec - that's what the spec says. But it is a bug in the spec.To identify that bug, you need another spec that can find fault with the official spec. Only the official spec is written down.
Here are some other common and widely-recognized bugs-in-the-spec:
- The conventional sign of the electric charge of protons and electrons has been reversed.
- Mathematical function applications are written before their argument, when they should be written after.
A bug is a feature that does what the code says it should do, not what the requirements say it should do (or shouldn't in the case of most bugs). When you understand that there's no difference between a bug and a feature in the code. They're both just code.
It's a correct statement, but when you're talking about memory safe languages it's true that memory safety helps you avoid writing code that doesn't do what you were expecting, so I'd still suggest memory safety matters for reducing the number of bugs.
I read it as an argument from the end user’s perspective. Kind of like this:
Indeed there are people who think like that, but usually they are people like my grandparents, whose level of software understanding boils down to “the Desktop is where I play Solitaire” and “Internet Explorer is the literal internet”.That's the simple version of it yes. I outlined a more complex version of it in a parallel answer. In short: lacking a complete specification of what to do, it's often impossible even within software teams to tell whether something is a bug.
And you never have a complete specification of what to do.
>an argument from the end user’s perspective
Well, the end user's perspective is buggy.
And a developer doesn't have to give the same semantics as the user, anymore than a medical equipment manufactured needs to consider its products based on what each random patient wants and what misconceptions or urban legends they believe.
The lack of a feature is not the same as a bug.
A bug means that there is a feature, but it's not behaving as was specified. (Or expected, or as it used to ... but clearly a difference to something, not to nothing)
It doesn't matter whether to the end user that's indistinguishable. It is for us, the professionals.
It's the same as with any other profession and domain-knowledge. If my heater doesn't work but it used to work, that's a bug, a regression. If it doesn't integrate with my smart home, that's not a bug. It was never a feature to begin with.
> If you have a bug to fix to weigh against a feature to add, which do you pick? The only correct answer is "The one that provides most value".
I agree.
> And again we see that it's very possible - even likely - that fixing the last bug will _never_ be as important as adding more features.
Depends entirely on the project and the revenue stream. I've open sourced code which I consider done. It does what it should do and I won't any more features to it.
I will however fix bugs within the existing functionalities.
When a program clearly deviates from its spec, would you be okay with calling that a "bug"?
There's always a gray area of what's intended by the spec, but a program can absolutely and blatantly deviate from the letter of the spec, and they often do.
This distinction seems worthwhile to me, because it means that something someone already relies on does not work (anymore), even though reasonable people would agree that, according to the spec, it should.
Absolutely would. But if we can categorize 1/3 of defects as ”bugs” 1/3 as ”missing or incomplete functionality” then there is 1/3 in the middle which we can’t decide. So the dichotomy is kind of weird, and making ”rules” and processes about this categorization is probably not worthwhile.
At least not worthwile for the purpose you have in mind. Okay, now I understand better what you mean, something like: for some purposes, there's not much to be gained by distinguishing between "bug" and "feature", one major reason being that there is no clear boundary between the two.
I first read your original comment in a much more absolute way (there is no distinction at all, and it never makes any sense anyway), which is quite easy to disagree with.
By "The one that provides most value", do you mean in the short or long term? Very often, in my experience, prioritizing so-called "quick wins" only quickly wins the codebase more tech debt, that puts the project on a sure path to development hell.
> do you mean in the short or long term?
The answer to that is sadly "yes".
> prioritizing so-called "quick wins" only quickly wins the codebase more tech debt, that puts the project on a sure path to development hell.
That's why we pay senior developers lots of money. Their gut feeling (or past scars) about what actually gives value across different horizons.
I imagine it's a difficult time to be a Zig developer.
In the near term, Bun choosing to switch from Zig to Rust specifically to fix all the memory errors seems to have done the Zig community some psychological damage.
But more significantly, in the medium term it looks likely that AI coding is going to overtake the industry before Zig gets properly established. And it is going to be very hard to justify choosing Zig for your sloppy-but-functional AI-written code - why open yourself up to memory unsafety on top of everything else? Further, the Zig community appears to value a hand-crafted, 'artisanal' approach to software development, which is the very antithesis of vibecoding.
I have no particular interest in Zig as a language but definitely feel some empathy here. The industry is changing in ways that many of us are struggling to process.
> I imagine it's a difficult time to be a Zig developer.
In some ways it always has been, the community was 'born' in the middle of the pandemic, then for a long time there was a constant influx of Rust zealots coming into threads about Zig to remark how immoral it is to use Zig, and now LLM shovel sellers are telling everybody that the only way forward is to become efficient at consuming tokens.
But it's actually not that bad.
The Zig community is growing pretty well, useful software is being written in Zig, and the advantages that Zig brings are still valid whether you hand-code or use LLMs (e.g. cross-compilation of C/C++ code).
This might be a very naive take on my part, but I don't think of vibecoding as a competitor to actual coding the same way I don't think of doing amphetamines (even if they make you more productive in the short term) as a competitor to being clean. I think it's a self-destructive behavior that is ultimately going to degrade your critical thinking skills, especially if you're a beginner. As with everything, the smarter your tools, the dumber you get. People often claim to acquire "higher level thinking" skills from it (as do meth users), but even if that's true, they are also currently teaching those skills to the very tools that try to replace them.
The question is why would you fare any better if you don't use it. I don't know how it will play out, but this much I know: I will never pay for AI music, because I can replicate it for free. I'm still buying music from real musicians (in fact tons more than ever before), because I can't. Similarly, I have contributed to many FOSS projects (both financially and in PRs), but will not (knowingly) do the same for the ones that are vibecoded. Whether that will amount to anything or is just a fart in the wind, we'll see.
> before Zig gets properly established.
zig is reasonably established. the llms write pretty good zig. see project linked below which is almost entirely llm-written
> And it is going to be very hard to justify choosing Zig for your sloppy-but-functional AI-written code
why? because one project that was shipping fast made a dog's breakfast of it?
> why open yourself up to memory unsafety on top of everything else?
this can be addressed by third parties in the reasonable near-term. for example:
https://github.com/ityonemo/clr
the zig team says that in the future stabilizing the IR and providing an API will happen.
fwiw in the process of building this project the llms have never once written a memory safety error in the "lib" section (in the src section there was a lot of tripping over segfaults since memory mapping datatypes accessed by a dylib can get hairy)
> the llms write pretty good zig
I doubt this from my personal experience. Every week after a release, I see tweets complaining how AI wrote some depreciated code because Zig is making breaking changes every release. (They are valid in doing so, it's just not AI friendly yet)
Agreed unfortunately, if Zigs whole selling point is meant to be a "nicer C" (and a much nicer DX than Rust because no fighting the borrow checker etc) - does that really matter in a world where an LLM is writing the code? I am not going to be fighting the borrow checker, the LLM is.
And as always, the response you'll hear is: but AI sucks/hallucinates/could never replace me etc... Just look at the progress LLM'S have made in the past few years, and extrapolate that to the next 10 or 20 years. I don't see how Zig makes sense if this is the trajectory the industry is going.
> Just look at the progress LLM'S have made in the past few years, and extrapolate that to the next 10 or 20 years.
First of all, past trend doesn't predict the future.
And if it did, then the answer would be nothing will matter in 20 years. Not just "no programming language," but nothing.
What does nothing matter mean thou ? The extrapolation is very plausible outcome thou
Why would *any* programming language matter when LLMs can just directly output binaries from a sufficiently detailed spec ;)
And specifically, why would Rust be a better choice than C or Zig when the LLMs get good enough to just write memory safe code in unsafe languages (they are already pretty good at finding memory safety bugs).
IMHO for code generation, different things start to matter (like fast build times, while 'convenient highlevel abstractions' become less important).
Writing memory safe code in unsafe languages requires global reasoning, which LLMs are terrible at. The whole point of a type system or a borrow checker like Rust's is to thread the requirements for safety throughout the program syntax in a way that makes it possible to spot problems locally. That's why LLMs tend to be rather good at writing Rust.
> Writing memory safe code in unsafe languages requires global reasoning
If you learn how to use arena allocators and in general use modern techniques, you don't need global reasoning to write correct memory management code pretty much never.
If your code is a RAII and abstraction maze, then yes, you will probably need global reasoning, but that's not the case with Zig.
Writing anything safe code in any language that doesn't have that safety built in requires global reasoning. That's why LLMs aren't better at writing rm-rf/-safe code in Rust.
Why's everybody obsessed with the popularity contest?
Rust is a great language with some great killer features.
It does not need consistent propaganda preaching how it's a better choice than "insert other language".
Every system programmer is aware of Rust and it's pros. Doesn't mean it's a language that fits the use case, project, constraints and even preferences. It's not just about generating code, it's also about reading it and maintaining it.
Thus some people just prefer alternatives, be it C, C3, Odin, Zig, Jai or whatever else there is.
You said it yourself, it's selling point is "nicer C", so it's for people that don't want to write Rust or C++ but a nicer C.
> It does not need consistent propaganda preaching how it's a better choice than "insert other language".
Indeed. There is an irrational urge in some folks to become language-missionaries. Usually such folks have gained expertise in that specific language and want to protect and expand their turf. There is a wide-range of software usecases requiring a variety of tools and no one language fits all.
Amusing side-note. xai was all-in on rust for their ai-stack back in 2023. But now, spacex controlled xai is apparently coding ai in C - perhaps with the attitude that if a language is good enough to control rockets it is good for ai.
Rustaceans tend to be extremely defensive and insecure as a community, overall they are quite toxic. That's the truth.
I think it's like this. People think differently. Someone finds a language that really fits the way they think, and it feels wonderful, and they feel like they've been let out of prison into this wonderful new freedom. And they, being empathetic humans, want other people to have the same experience, and they think that others will have the same experience if they just try this wonderful language. So they become language missionaries.
But what they miss is that other people think differently than them. Other people will feel let out of prison by a different language.
> In the near term, Bun choosing to switch from Zig to Rust specifically to fix all the memory errors seems to have done the Zig community some psychological damage.
Meanwhile, some projects are doing the opposite, like going from Rust to Zig, here's an example from a podcast I recently listened to: https://www.youtube.com/watch?v=XSXGf3oN2yU
Here's the project in question: https://github.com/roc-lang/roc
I think Bun just got a lot of visibility because of the speed and scope of the migration, which both shook things up and I guess was good PR cause that made a lot of headlines.
I wish Roclang well but (as a regular listener to Feldman's podcast) I don't think we can draw many conclusions from this switch other than "Feldman has lots of opinions on lots of things".
You can replace the product and author name with Bun and the Bun author and the sentence also works, in the end all technical decisions are based on "opinions".
I mean, personally I just hope that at the end of the day everyone is as happy as the technologies in question will permit them to be. Either way I wouldn't say that Zig is done even after such prominent/loud news as the Bun rewrite.
Why do people even try to vibe-code stuff in low level languages?
You either care about non-functional aspects of your code, or you don't. Running your code through the shredder that destroys everything you don't test while insisting on writing it on a language that specifies non-functional properties... I don't have any other word, it's stupid.
Control and performance, the same reasons why people write in low level languages today/yesterday instead of everything in Python or JS.
Not all vibe coding is top down "Claude build X", it can be very specific implementation guidelines and criteria.
I don't understand the idea behind Zig. What I have read sounded like "let's make a language like Rust, but not memory-safe", which doesn't make a lot of sense to me.
Even Rust has an unsafe subset. There's a meaningful question about how to make such an unsafe language as easy and comfortable to use as possible, and Zig is a decent answer to that particular question. The libraries Zig ships with are especially relevant here, rather than the core language per se: Rust's library facilities are outright terrible to write unsafe code with, because the usual requirements of safe code are assumed throughout and the whole point of unsafe code is to break those. (You can selectively relax those requirements, e.g. take &Cell<T> not &mut T, to allow for benign aliasing - but most stdlib code doesn't bother to!)
"Like unsafe Rust, but more convenient to use" is basically every imperative language around there, I still don't understand the specific niche that Zig intended to fill
I am not optimistic. When I look back in history, “worse is better” won every time. And vibecoding is the current epitome of “worse is better”. There are many places where code is a necessary evil, just a means to an end. And when the resulting software has never been particularly good anyway, then vibe-coded slop might just be good enough. Eventually, the economics will decide. There is a small chance that rising costs of LLM usage might save a segment or two from being devoured altogether.
1. Fixing memory errors wasn't the reason the project migrated to Zig, but a beef between the Bun maintainer not getting his own changes in the upstream compiler and the Bun's new employer focus on Rust.
2. You can write memory safe code in C (Redis, SQLite, OpenBSD, Git, etc), let alone in Zig which provides more tools to write memory safe code.
3. AI can write very good Zig already. This isn't 2024 anymore where "the LLM has seen lots of this language so will write better in this language" scenario existed. Will make you an example: I have worked in a very esoteric typescript fork called TS plus (providing among others fluent style apis for pipe-able functions) and even Opus 4.1 did well. Recently I have forked the Elm language and the LLM had no problem dealing with it, despite significant differences to the original Elm.
4. Zig's community uses Zig because it likes Zig and its tooling and doesn't like the constraints of other languages. Simple as that.
Writing memory safe code in C with (most) compilers slapping UB in your face without so much as a warning is about the same as vibecoding.
Believe what you want, I guess.
https://xcancel.com/jarredsumner/status/2055796104302858694#...
> I’m just tired of dealing with crashes and memory leaks & want language features to help prevent things
(Edit: this reply seemed less flippant before the parent edited their reply)
The truth is a bit of everything, bun being a messy codebase written primarily with "move fast and break things" in mind, cultural divergence between Bun and the Zig community, and also hiring issues. People maybe forgot but Jarred at some point caused a bunch of drama when he tweeted that working at Bun is not for people that value life/work balance, which went viral and caused an uproar. Must not have been super easy to hire from the Zig community after that, and in fact once Bun got acquired by Anthropic, it was pretty much Jarred and Claude doing all the work on the codebase. Pivoting to Rust is probably at least in part a way to reset the clock on those hiring interactions.
It is really inspiring to see other people passionate about programming. Really love the people building zig. Especially Andrew and Loris and some other people I saw in codeberg
Thanks, yeah Andrew gave a pretty good interview to the JetBrains people recently https://www.youtube.com/watch?v=iqddnwKF8HQ
Not all software is about usefulness. Especially in context of hacking, where software is a way of self expression and making something fun.
In enterprise usefulness is not the end goal either. Software can be very useful, but if no one is going to pay for it, it holds very little value for the business.
I have voiced a similar thought more succinctly: “it is your worst software that will live forever.”
The implication is that you should always strive to release software that isn’t overly buggy, isn’t slow, and is general a pleasure to use.
recently i've ran into products that feel like they were not meant to be used, but instead just follow some specification list.
for me, the end user's experience goes above all.
There's a weird theme I've seen in some American companies, where they will avoid communicating with the end user and letting everything be one sided
> I do not hear the end user, therefore it does not exist
Not literally, but that's what it feels like.
It's probably safer, but in the long run you're not building any trust.
Extremely similar to the Robot Laws.
"Fix all bugs"?
No bug left behind
Damn this person's obviously is so bitter towards Rust... I wonder why he's so obsessed with it?
I mean, if they really care about software correctness, I wonder why take a very discutibile position and say that "safety doesn't matter if you don't use the correct process". Yeah, I mean, having some guardrails is better than none, right? If they really cared about correctness, they would really strive to put all the possible guardrails in place, wouldn't they? Maybe they are bitter because their fav language is not as popular as the other?
But there are so many languages, I wonder why picking on Rust specifically.
I don't get it. Are we reading the same article? This article is so generic that it reads like vacuous truth to me. But I don't see their bitterness towards Rust (or anything, really. It's just vacuous.) from it. Is this person a famous anti-rust'er or something?
But it links to this post
https://joshlf.com/posts/memory-safety-life-and-death/
Under a "it doesn't matter it's memory-safe if..."
You may be misinterpreting the intended meaning.
It's like saying it doesn't matter if surgery is done another antiseptic conditions if the patient isn't also given a course of antibiotics during recovery.
It's not an argument against safe practices, it's an argument for amending one kind of safety with others.
Antiseptics did make a big difference in the century before antibiotics...
I don't get how you dont't get. It links about memory safety (with a link towards an extremely biased article in Rust's favor) and a link to design to correctness (that leads to Zig project).
There is a lot to dislike about this paragraph:
Hang on. If I want to prevent all bugs, shouldn't memory safe make your correctness much easier to achieve? And what is this about fixing all bugs? You mean proofs? The stuff that Zig doesn't aim to do?And no, asserts don't fix all bugs, they just guarantee some of your invariants are held at best, used in test at worst.
Not if choosing statically checked memory safety sacrifices for correctness where it is a local optimum
If you sacrifice memory safety for correctness, that just means it's not correct. If safety is crucial, it must be safe under all inputs, and if there are data races.
It's a bit like saying, "Yeah, our system is safe, but if there are two threads racing or use after free somewhere, then all bets are off."
> It doesn’t matter that the language you use is memory-safe
> nobody can trick me into mistaking lesser stars for my true destination
The author seems to be in some level of denial around compile-time safety checks. They're right that runtime safety errors are an issue, but it feels wrong to discount compile time checkers when it can save a lot of yak shaving.
Quote the entire sentence.
>It doesn’t matter that the language you use is memory-safe, if you didn’t design for correctness or have no process that will eventually lead you to fixing all bugs.
It's also worth noting that they linked a post about how memory safety is literally a matter of life and death, so it seems like their point is that memory safety is one class of bug, and a compiler guarantee about it doesn't equate to a guarantee of correct, bugless, unexploitable code.
Like, the linked author brought up that Khashoggi's wife's phone was hacked. Maybe that was due to a memory bug or some other kind of bug. Maybe the next journalist who gets hacked is a victim of a memory bug or some other kind of bug. But that linked post didn't take a holistic view of correctness, but went straight to, "Rust is safe. Rust saves lives." There's a logical error there that's being pointed out.
If you really want to save lives, you need to eliminate exploits. Not just do a victory lap because your compiler ostensibly eliminates one class of them. The compiler doesn't catch all bugs. The compiler isn't the only tool for catching bugs.
That's my reading of it, anyway. I think he has a point, and the Rust people do as well. I think it's wrong to portray him as bitter.
That is correct, this blog post is about understanding the priority of various subgoals and the ultimate goal (creating useful software). Memory-safety is important but overfitting on that subgoal, as I believe the memory-safety blog post is doing, won't make you create better software.
If Rust helps you get all the way to correctness, then great, but that blog post was insane.
> The compiler doesn't catch all bugs. The compiler isn't the only tool for catching bugs.
I acknowledged that in my prior comment. This person is letting perfect be the enemy of good, and I guarantee you that they aren't running their binaries through Valgrind and Ghidra to check the runtime safety after it's built.
Exploits like Heartbleed get shipped because people abdicate their responsibility to write safe software. Shackling developers to dynamic analysis tools is not any better of a solution than using a memory-safe language to start. Rust is shaving a calf to avoid the whole yak.
It's so bland and generic its bizarre like somebody is botting it. Weird that all the comments calling this out are getting flagged or downvoted.
What 'all the comments'? There aren't many comments in this thread. You mean this: https://news.ycombinator.com/item?id=48432736 ? I flagged it too. I think the flag is quite justified.
oh I don't particularly care I'm just asking what is it about this article that is so worthy of being front page? I'm literally just calling out the content. I'm sorry for complaining.
It’s getting attention because the subtext of the article is the zig vs AI ideological battle going on (and zig vs Rust somewhat on the backburner)
Recent events AFAIU: - bun (bought by big AI) switching to Rust - zig team banning AI pull requests (because they want to review humans) - The cloud industry buying all coding tooling companies (uv, vite, bun) but zig being unbuyable
If anybody from the zig core team is reading this: thank you and carry on the good work.
so im just getting caught up with zig is I have never really paid attention to it
so far I'm not really getting zig and I see they banned AI ? seems like that is just going to attract anti-AI user base...not sure if that was a wise decision.
also not really sure why anyone would migrate from Rust to Zig, it seems much less mature and unsure of the ROI there.
I think you will be surprised by how many developers do not have this same list of priorities (or in that order) when developing software.
I posted this link at the same time when I posted it to Lobsters (https://lobste.rs/s/g6lkw1/my_software_north_star) 3 days ago, but it didn't get on the front page. Seeing that the submission time has been reset, I imagine it was given a second chance by HN curators (it's a known process), but that doesn't mean free upvotes, it's just that some people resonate with the thinking.
It's bland and generic because it's a manifesto. Author (and HN submitter) is Loris Cro, aka @kristoff_it, VP of Community at Zig Software Foundation.
In his role, devising as set of general guidelines to use as compass when things (inevitably! and often!) get very very muddy and Right v. Wrong is hard to tell apart -- both objectively, and also from the point of view of being a community leader with ton of vested interest -- is essentially one half of his job. Other half is abide to said guidelines.
So @kristoff_it last week sat down, came up with three simple rules short enough he can print on a business card (or hang on his office wall or whatever), and posted them here to test if they make sense to the wider community.
TLDR: yes can seem bland / generic but within context it makes sense to me author needed to distill his ethics in a nutshell.
oh. I've never heard of zig. I use Rust.
Fair :)
I'm tourist in Zig land too, follow Kristoff / A. Kelley etc, Tiger Beetle DB (written in Zig) and stuff, but only as observer / bystander.
the piece didn't really seem very targeted at Rust as much as it's targeted at projects claiming to be secure just because they're written in Rust
Agree, the claim "secure because Rust" is wrong. But "more secure than if it were written in an unsafe language" is probably going to be true most of the time.
Nah. You’re assuming that the developer has some experience. The false assurance that the magic of Rust will protect the developer from himself/herself will lead that young developer to make worse decisions. An experienced developer typically has discernment, and has learned, rather painfully, that he/she can make serious errors in any language.
from his about page: "I'm VP of Community at the Zig Software Foundation"
EDIT: doesn't really answer your question. Just reminds me of a good ol' flamewar.
> Damn this person's obviously is so bitter towards Rust
What makes you think that?
> I wonder why picking on Rust specifically.
I did not see that. What did I miss?
The adjective 'useful' is doing a lot of the heavy-lifting here.
What kind of 'useful'? Normative? Empirical? Prescriptive? Pragmatic?
'Useful' is a very subjective north star.
>What kind of 'useful'?
Someone says it's useful to them. If you get a consensus where >50% find it useful, then it's probably useful.
Ok, that's empirically useful by argument of popularity.
By that same measure: correctness, maintainability, and efficiency are not that useful.
I wasn't saying usefulness is not important, I'm saying this post conveniently crammed the hardest problem of writing software into a fuzzy adjective.