Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Software North Star

kristoff.it

Post reply on HN
Print view View original

41–50 of 166 posts

Re: My Software North Star

#41

Post by bsza »

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…

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.

Re: My Software North Star

#42

Post by thrance »

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…

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.

Re: My Software North Star

#43

Post by alkonaut »

thrance wrote: post #42
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…

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.

> do you mean in the short or long term?

The answer to that is sadly "yes".

> prioritizing so-called "quick wins" only quickly wins the codebase more tech debt, that puts the project on a sure path to development hell.

That's why we pay senior developers lots of money. Their gut feeling (or past scars) about what actually gives value across different horizons.

Re: My Software North Star

#44

Post by onion2k »

0815beck wrote: post #37
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…

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

A bug is a feature that does what the code says it should do, not what the requirements say it should do (or shouldn't in the case of most bugs). When you understand that there's no difference between a bug and a feature in the code. They're both just code.

It's a correct statement, but when you're talking about memory safe languages it's true that memory safety helps you avoid writing code that doesn't do what you were expecting, so I'd still suggest memory safety matters for reducing the number of bugs.

Re: My Software North Star

#45

Post by tikhonj »

alkonaut wrote: post #39
0815beck wrote: post #37

Earlier quoted context omitted.

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

There is a pretty clear and important difference between a program that does something wrong, and a program that just doesn't do something somebody wants.

"You don't support printing", "pressing the print button doesn't print", "pressing the print button crashes the computer" and "pressing the print button lets an attacker get root access to the system" are all different and it makes sense to distinguish them. (The first is a missing feature, the second and third are different kinds of bugs, the last is a special kind of bug we call a security vulnerability.)

That distinction might not be useful to end-users, but it's useful for the people building the system! If you want to care about quality, committing to a strategy like "we will not add features before we fix known bugs" is totally clear, reasonable and effective. There might be some frontier of issues where it's hard to make a distinction, but that just means there are subtle edge-cases, not that the whole concept is undefined. A lot of perfectly cromulent concepts have edge-cases! You can just decide those on a case-by-case basis; if it's actually so close as to be legitimately confusing—it's not just feigned ignorance or political posturing—which side you choose probably doesn't have much of an effect.

This does depend on having a reasonably clear idea of what you're building, but that "reasonably clear idea" does not have to be anywhere near the detail of a "full spec", much less anything formalized. To me, that seems like a baseline you'd need to build quality software at all, and hardly an unreasonable thing to expect. And if most teams can't manage, well, it's just another explanation for why most software is crap.

Re: My Software North Star

#46

Post by hnthrow0287345 »

nilirl wrote: post #21

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.

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

Re: My Software North Star

#47

Post by flohofwoe »

Zakis1 wrote: post #25
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…

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

Why would *any* programming language matter when LLMs can just directly output binaries from a sufficiently detailed spec ;)

And specifically, why would Rust be a better choice than C or Zig when the LLMs get good enough to just write memory safe code in unsafe languages (they are already pretty good at finding memory safety bugs).

IMHO for code generation, different things start to matter (like fast build times, while 'convenient highlevel abstractions' become less important).

Re: My Software North Star

#48

Post by dxdm »

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…

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.

Re: My Software North Star

#49

Post by epolanski »

Zakis1 wrote: post #25
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…

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

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 reading it and maintaining it.

Thus some people just prefer alternatives, be it C, C3, Odin, Zig, Jai or whatever else there is.

You said it yourself, it's selling point is "nicer C", so it's for people that don't want to write Rust or C++ but a nicer C.

Re: My Software North Star

#50

Post by raincole »

Zakis1 wrote: post #25
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…

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

> Just look at the progress LLM'S have made in the past few years, and extrapolate that to the next 10 or 20 years.

First of all, past trend doesn't predict the future.

And if it did, then the answer would be nothing will matter in 20 years. Not just "no programming language," but nothing.

Post reply on HN