Hacker News

>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.

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.

> 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.

> 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.

"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

what do you mean "there is no way to distinguish a feature from a bug"? of course there is

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.

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 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)

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.

> 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.

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.

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.

Thanks, yeah Andrew gave a pretty good interview to the JetBrains people recently https://www.youtube.com/watch?v=iqddnwKF8HQ

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.

No bug left behind

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?

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

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?

>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.