My Software North Star • Hacker News Board

Re: My Software North Star

#101

Post by AnimalMuppet » Sun, Jun 07, 2026, 4:16 PM UTC

coldtea wrote: post #75

alkonaut wrote: post #34

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

> 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 i…

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.

Re: My Software North Star

#102

Post by AnimalMuppet » Sun, Jun 07, 2026, 4:24 PM UTC

bwfan123 wrote: post #97

epolanski wrote: post #49

Earlier quoted context omitted.

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…

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

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.

Re: My Software North Star

#103

Post by demorro » Sun, Jun 07, 2026, 4:47 PM UTC

alkonaut wrote: post #34

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

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.

Re: My Software North Star

#104

Post by dxdm » Sun, Jun 07, 2026, 4:47 PM UTC

alkonaut wrote: post #89

dxdm wrote: post #48

Earlier quoted context omitted.

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…

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.

Re: My Software North Star

#105

Post by Levitz » Sun, Jun 07, 2026, 4:48 PM UTC

alkonaut wrote: post #86

coldtea wrote: post #75

Earlier quoted context omitted.

> 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 i…

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.

Re: My Software North Star

#106

Post by somat » Sun, Jun 07, 2026, 5:00 PM UTC

alkonaut wrote: post #34

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

"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

Re: My Software North Star

#107

Post by BiraIgnacio » Sun, Jun 07, 2026, 5:14 PM UTC

alkonaut wrote: post #34

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

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

Re: My Software North Star

#108

Post by data-ottawa » Sun, Jun 07, 2026, 5:27 PM UTC

marcosdumay wrote: post #94

flooow wrote: post #7

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…

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.

Re: My Software North Star

#109

Post by epolanski » Sun, Jun 07, 2026, 5:31 PM UTC

bwfan123 wrote: post #97

epolanski wrote: post #49

Earlier quoted context omitted.

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…

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

[flagged]

Re: My Software North Star

#110

Post by bigyabai » Sun, Jun 07, 2026, 5:35 PM UTC

mcdonje wrote: post #20

bigyabai wrote: post #9

Earlier quoted context omitted.

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

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