8 ms·

My Software North Star

220 points by kristoff_it 4mo ago

randypewick 4mo ago
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.
- mobelkh 4mo ago
  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
  - Zakis1 4mo ago
    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.
    - BirAdam 4mo ago
      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.
      - kibwen 4mo ago
        No. Rust is excellent for beginner programmers dipping their toes into systems programming for the first time. Imagine you have a million-line C codebase, and a brand-new junior hire. Are you going to unleash them on the codebase unsupervised? Hell no, you're going to need to watch them like a hawk and regularly slap their fingers in order to teach them what not to do. But I would gladly unleash a junior on a million-line Rust codebase, as long as I have a CI rule that flags any PRs that touches files containing the `unsafe` keyword. This frees up the junior to spend more time learning the business domain and less time worrying about bizarre memory errors.
- ares623 4mo ago
  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.
  - randypewick 4mo ago
    Thank you for this info! So they are on the payroll of the ZSF. It's likely just a marketing job then, and not a flame war, or maybe an opportunistic flame war.
- worik 4mo ago
  > 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?
  - randypewick 4mo ago
    Well, maybe I'm biased! It just stood out, so I felt it was picking.
- raincole 4mo ago
  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?
  - bigyabai 4mo ago
    > 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.
    - mcdonje 4mo ago
      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.
      - kristoff_it 4mo ago
        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.
flooow 4mo ago
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.
- dnautics 4mo ago
  > 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 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)
  - rirze 4mo ago
    > 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)
    - dnautics 4mo ago
zuzululu 4mo ago
[flagged]
nilirl 4mo ago
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.
- hnthrow0287345 4mo ago
  >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.
  - nilirl 4mo ago
    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.
ozgrakkurt 4mo ago
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
- kristoff_it 4mo ago
  Thanks, yeah Andrew gave a pretty good interview to the JetBrains people recently https://www.youtube.com/watch?v=iqddnwKF8HQ https://www.youtube.com/watch?v=iqddnwKF8HQ
alkonaut 4mo ago
> 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).
- 0815beck 4mo ago
  what do you mean "there is no way to distinguish a feature from a bug"? of course there is
  - jihadjihad 4mo ago
    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”.
    - alkonaut 4mo ago
      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.
boxed 4mo ago
Extremely similar to the Robot Laws.
vladde 4mo ago
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.
- ramon156 4mo ago
  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.
graphviz 4mo ago
"Fix all bugs"?
- timedude 4mo ago
  No bug left behind
BirAdam 4mo ago
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.
ivanjermakov 4mo ago
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.
- thot_experiment 4mo ago
  You're so close to getting it!

220 points by kristoff_it 4mo ago

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.

mobelkh 4mo ago
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
- Zakis1 4mo ago
  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.
  - BirAdam 4mo ago
    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.
    - kibwen 4mo ago
      No. Rust is excellent for beginner programmers dipping their toes into systems programming for the first time. Imagine you have a million-line C codebase, and a brand-new junior hire. Are you going to unleash them on the codebase unsupervised? Hell no, you're going to need to watch them like a hawk and regularly slap their fingers in order to teach them what not to do. But I would gladly unleash a junior on a million-line Rust codebase, as long as I have a CI rule that flags any PRs that touches files containing the `unsafe` keyword. This frees up the junior to spend more time learning the business domain and less time worrying about bizarre memory errors.
ares623 4mo ago
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.
- randypewick 4mo ago
  Thank you for this info! So they are on the payroll of the ZSF. It's likely just a marketing job then, and not a flame war, or maybe an opportunistic flame war.
worik 4mo ago
> 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?
- randypewick 4mo ago
  Well, maybe I'm biased! It just stood out, so I felt it was picking.
raincole 4mo ago
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?
- bigyabai 4mo ago
  > 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.
  - mcdonje 4mo ago
    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.
    - kristoff_it 4mo ago
      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.

flooow 4mo ago

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.

dnautics 4mo ago
> 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 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)
- rirze 4mo ago
  > 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)
  - dnautics 4mo ago

zuzululu 4mo ago

[flagged]

nilirl 4mo ago

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.

hnthrow0287345 4mo ago
>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.
- nilirl 4mo ago
  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.

ozgrakkurt 4mo ago

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

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

alkonaut 4mo ago

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

0815beck 4mo ago
what do you mean "there is no way to distinguish a feature from a bug"? of course there is
- jihadjihad 4mo ago
  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”.
  - alkonaut 4mo ago
    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.

boxed 4mo ago

Extremely similar to the Robot Laws.

vladde 4mo ago

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.

ramon156 4mo ago
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.

graphviz 4mo ago

"Fix all bugs"?

timedude 4mo ago
No bug left behind

BirAdam 4mo ago

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.

ivanjermakov 4mo ago

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.

thot_experiment 4mo ago
You're so close to getting it!