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

Stability by Design

potetm.com

Post reply on HN
Print view View original

61–67 of 67 posts

Re: Stability by Design

#61

Post by exac »

mwcampbell wrote: post #60
Animats wrote: post #3

I'm currently struggling with instability in the Rust 3D graphics stack. All this stuff has been around for about five years now, and was mostly working five years ago. The APIs should have settled down long ago. Despite this, there are frequent "refactorings" which cause breaking changes to APIs. (I'm tempted to term this "refuckering".) Some of this API churn is just renaming types or enum values for consistency, o…

As a contributor to the Rust GUI ecosystem [1], I've been affected (somewhat) by that churn and have also contributed to it. The best defense I can give for doing what might be considered refuckering is that when my library eventually hits 1.0, I want to meet the same standard of stability as Rust itself, and when that point comes, as @munificent said [2], I want my library to represent my best understanding of how t…

Would you consider https://0ver.org/ instead?

Re: Stability by Design

#62

Post by phoronixrly »

lmm wrote: post #27
phoronixrly wrote: post #9

Earlier quoted context omitted.

Maybe that's a bad example, as your build can fail because of a breaking change in a dependency regardless of whether you use a statically typed language. Also your statement is only partially correct. Breaking changes in dependencies end up in production only if you don't have tests. And I know this is news to many people using static types but in many Ruby shops for example there are test coverages in excess of 90%…

A test suite often ends up acting as an ad-hoc, informally specified, buggy, slow implementation of half a static type system yes.

I mean sure, if your test suite does fuzzing, then I guess so. Most test suites focus on higher level stuff like behaviours and entire features these days. This is instead of testing in isolation the technicalities like the signatures of functions and what happens if you pass a null here or there.

Re: Stability by Design

#63

Post by KronisLV »

potetm wrote: post #53
KronisLV wrote: post #45

Earlier quoted context omitted.

> code retention charts I really liked those charts, I wonder how you can generate them, whether there's a tool out there that you can just feed a Git repo into or something.

pip install git-of-theseus git clone repo cd repo git-of-theseus-analyze . git-of-theseus-stack-plot cohorts.json

Thank you! This was super useful!

Re: Stability by Design

#64

Post by munificent »

mwcampbell wrote: post #59
munificent wrote: post #15

It's true that if you always add new functions to your library instead of changing existing ones then users can upgrade without breaking. There is real value in that. But woe unto the user who first starts using your library after a decade of that "evolution" and they are faced with a dozen functions that all have similar but increasingly long names and do very similar things with subtle but likely important differen…

It's no wonder that newcomers to Win32 find it intimidating.

And C++ for that matter.

Re: Stability by Design

#65

Post by lmm »

phoronixrly wrote: post #62
lmm wrote: post #27

Earlier quoted context omitted.

A test suite often ends up acting as an ad-hoc, informally specified, buggy, slow implementation of half a static type system yes.

I mean sure, if your test suite does fuzzing, then I guess so. Most test suites focus on higher level stuff like behaviours and entire features these days. This is instead of testing in isolation the technicalities like the signatures of functions and what happens if you pass a null here or there.

The same applies to type systems these days - you don't just express basics like nullable or not, you build high level business concerns into your types.

Re: Stability by Design

#66

Post by simultsop »

lelanthran wrote: post #41
phoronixrly wrote: post #9

Earlier quoted context omitted.

Maybe that's a bad example, as your build can fail because of a breaking change in a dependency regardless of whether you use a statically typed language. Also your statement is only partially correct. Breaking changes in dependencies end up in production only if you don't have tests. And I know this is news to many people using static types but in many Ruby shops for example there are test coverages in excess of 90%…

> Breaking changes in dependencies end up in production only if you don't have tests. Which are opt-in in dynamically typed languages. You get the same functionality in statically typed languages and it's not opt-in , AND the developer doesn't have to do the work of type-checking (the compiler does it).

In a utopic scenario, yes, you fix type-checking and you can live happily ever after.

In an interoperable environment, when additional programming languages/teams are in play, which is very frequent nowadays. You have the problem of centralizing types/entities/schemas, reused types, partial types, and union types, and you can keep the story on.

At some point, instead of typing being an invisible tool, it becomes the tool. Then you superset the tool to other languages, because they are in an immutable state. Another language will emerge with dynamic typing in decades then people will take the same spiral and spend more time to reason wages.

Re: Stability by Design

#67

Post by jrvieira »

exac wrote: post #61
mwcampbell wrote: post #60

Earlier quoted context omitted.

As a contributor to the Rust GUI ecosystem [1], I've been affected (somewhat) by that churn and have also contributed to it. The best defense I can give for doing what might be considered refuckering is that when my library eventually hits 1.0, I want to meet the same standard of stability as Rust itself, and when that point comes, as @munificent said [2], I want my library to represent my best understanding of how t…

Would you consider https://0ver.org/ instead?

How would 0ver contribute to anything positive here?
Post reply on HN