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?
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.
There are performance reasons to handle memory allocation manually and tactically. This is why languages which deal with memory manually are not going anywhere.
Whether Zig will become dominant in that space remains to be seen.
For me personally I found Zigs AI stance and the artisanal mindset very attractive.
So much so that I am at the moment doing the ziglings exercises and learning it over Rust (which I gave up on some time in the past, because it didn't spark "joy" for me; so far Zig does).
Sure, for now it is just a hobby programming lang to me, but it might become more than that.
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
> 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).
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.
18 comments
[ 3.5 ms ] story [ 40.5 ms ] threadI 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.
EDIT: doesn't really answer your question. Just reminds me of a good ol' flamewar.
What makes you think that?
> I wonder why picking on Rust specifically.
I did not see that. What did I miss?
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.
Whether Zig will become dominant in that space remains to be seen.
So much so that I am at the moment doing the ziglings exercises and learning it over Rust (which I gave up on some time in the past, because it didn't spark "joy" for me; so far Zig does).
Sure, for now it is just a hobby programming lang to me, but it might become more than that.
What kind of 'useful'? Normative? Empirical? Prescriptive? Pragmatic?
'Useful' is a very subjective north star.
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).
for me, the end user's experience goes above all.
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.
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.