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
My Software North Star
31–40 of 166 posts
Re: My Software North Star
#32Earlier quoted context omitted.
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 in…
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.
Re: My Software North Star
#33It 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
Re: My Software North Star
#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 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).
Re: My Software North Star
#35Damn 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 p…
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.
Re: My Software North Star
#36I 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…
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.
Re: My Software North Star
#37> 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…
what do you mean "there is no way to distinguish a feature from a bug"? of course there is
Re: My Software North Star
#38> 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…
what do you mean "there is no way to distinguish a feature from a bug"? of course there is
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
Re: My Software North Star
#39> 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…
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?
Re: My Software North Star
#40Earlier quoted context omitted.
what do you mean "there is no way to distinguish a feature from a bug"? of course there is
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 inte…
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.