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

111–120 of 166 posts

Re: My Software North Star

#111

Post by oytis »

zozbot234 wrote: post #92
oytis wrote: post #84

Earlier quoted context omitted.

I don't understand the idea behind Zig. What I have read sounded like "let's make a language like Rust, but not memory-safe", which doesn't make a lot of sense to me.

Even Rust has an unsafe subset. There's a meaningful question about how to make such an unsafe language as easy and comfortable to use as possible, and Zig is a decent answer to that particular question. The libraries Zig ships with are especially relevant here, rather than the core language per se: Rust's library facilities are outright terrible to write unsafe code with, because the usual requirements of safe code…

"Like unsafe Rust, but more convenient to use" is basically every imperative language around there, I still don't understand the specific niche that Zig intended to fill

Re: My Software North Star

#112

Post by gobdovan »

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…

Grandparent is onto something. You can't define correctness without a spec. And since most business-oriented software, which most of us work with, isn't made against a comprehensive spec, you can argue that anything falling outside it is either a bug or a feature. 'If your disk backup software corrupts backups' has behind it a clean definition that's (pretty) unambiguous and you don't care about, since it's already outsourced to some cloud solution. But 'User finds it easy to buy more stuff' does not.

Also, mandatory Sussman reference [0], where he talks about correctness not being that important and gives Google as example, that just needs to be close enough and not disastrously incorrect + interesting stuff around engineers confusing brittleness with correctness.

[0] https://www.youtube.com/watch?v=HB5TrK7A4pI

Re: My Software North Star

#113

Post by xboxnolifes »

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…

An unuseful-in-99%-of-cases definition of bug would be "any behavior that is not in the spec is a bug". But that would mean not shipping fast and breaking things. And having a spec.

Re: My Software North Star

#114

Post by thot_experiment »

ivanjermakov wrote: post #96

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.

You're so close to getting it!

Re: My Software North Star

#115

Post by n42 »

Ygg2 wrote: post #98
n42 wrote: post #72

Earlier quoted context omitted.

Not if choosing statically checked memory safety sacrifices for correctness where it is a local optimum

If you sacrifice memory safety for correctness, that just means it's not correct. If safety is crucial, it must be safe under all inputs, and if there are data races. It's a bit like saying, "Yeah, our system is safe, but if there are two threads racing or use after free somewhere, then all bets are off."

you do not sacrifice memory safety. you sacrifice a compiler ensuring that code is memory safe by it enforcing one quite opinionated approach to it: RAII and lifetime analysis.

you seem to think there is one path to memory safety. there is not. unsurprisingly, some programmers may need different tools when working with a different set of requirements.

Re: My Software North Star

#116

Post by J_Shelby_J »

kristoff_it wrote: post #62
zozbot234 wrote: post #61

Earlier quoted context omitted.

Writing memory safe code in unsafe languages requires global reasoning, which LLMs are terrible at. The whole point of a type system or a borrow checker like Rust's is to thread the requirements for safety throughout the program syntax in a way that makes it possible to spot problems locally. That's why LLMs tend to be rather good at writing Rust.

> Writing memory safe code in unsafe languages requires global reasoning If you learn how to use arena allocators and in general use modern techniques, you don't need global reasoning to write correct memory management code pretty much never. If your code is a RAII and abstraction maze, then yes, you will probably need global reasoning, but that's not the case with Zig.

The billion dollar “if”

Re: My Software North Star

#117

Post by jeremyjh »

alkonaut wrote: post #43
thrance wrote: post #42

Earlier quoted context omitted.

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.

Very few of them have worked on a single system for more than four or five years, and have no idea what their decisions cost after they left. Many have joined a project after four or five years and suffered from those decisions, but they don't actually know why the decisions were made - how things looked at the time those decisions were made - and so they can make the same mistakes in their next greenfield project.

Of course, some systems have to ship at all costs or there won't be a second or third year, so judgement is still required.

But a lot of experienced people still underweight the costs of having lots of "low impact" defects.

Re: My Software North Star

#118

Post by Ygg2 »

n42 wrote: post #115
Ygg2 wrote: post #98

Earlier quoted context omitted.

If you sacrifice memory safety for correctness, that just means it's not correct. If safety is crucial, it must be safe under all inputs, and if there are data races. It's a bit like saying, "Yeah, our system is safe, but if there are two threads racing or use after free somewhere, then all bets are off."

you do not sacrifice memory safety. you sacrifice a compiler ensuring that code is memory safe by it enforcing one quite opinionated approach to it: RAII and lifetime analysis. you seem to think there is one path to memory safety. there is not. unsurprisingly, some programmers may need different tools when working with a different set of requirements.

If you're using Zig to write correct by design code you do.

Or at least you have to add memory safety as another extra step on your road to correct by design.

I'm aware of paths to memory safety, but they boil down to: pervasive GC, annoying compiler, and praying you got it right.

If you write your proof in GC language than translate it to C, that's just a mix of pervasive GC and praying.

Re: My Software North Star

#119

Post by [deleted] »

zaphirplane wrote: post #74
raincole wrote: post #50

Earlier quoted context omitted.

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

What does nothing matter mean thou ? The extrapolation is very plausible outcome thou

[deleted]

Re: My Software North Star

#120

Post by Ygg2 »

zaphirplane wrote: post #74
raincole wrote: post #50

Earlier quoted context omitted.

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

What does nothing matter mean thou ? The extrapolation is very plausible outcome thou

https://xkcd.com/605/

No one can predict the future least of all humble extrapolation line.

Post reply on HN