Stability by Design • Hacker News Board

Re: Stability by Design

#21

Post by [deleted] » Fri, May 09, 2025, 4:17 AM UTC

potetm wrote: post #11

alexjurkiewicz wrote: post #10

I think code retention charts will look similar for any major library in any language. Projects accrete code. You could instead consider: * How many major version releases / rewrites happen in this language? (This might be a sign of ecosystem instability.) * How much new code is replacing old code? (This might imply the language needs more bugfixes.)

Not sure what you mean. The Scala example looks nothing like the Clojure examples. The retention charts show you how much new code is replacing old code, and you can see the releases/rewrites as the code gets replaced.

[deleted]

Re: Stability by Design

#22

Post by simultsop » Fri, May 09, 2025, 4:27 AM UTC

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…

In a world where everything means everything, fighting ambiguity is not an easy task. Hence the refactoring.

> When there's a bug, there's no going back to an older version.

This practice is developed by the industry for a reason. It would be really silly to hear people running AI in Windows XP.

> Most users are giving up.

Rust is pretty new, users shouldn't rush to switch a stack because of hype. It takes time for languages to mature, even more for the ecosystem.

Re: Stability by Design

#23

Post by chatmasta » Fri, May 09, 2025, 4:34 AM UTC

potetm wrote: post #11

alexjurkiewicz wrote: post #10

I think code retention charts will look similar for any major library in any language. Projects accrete code. You could instead consider: * How many major version releases / rewrites happen in this language? (This might be a sign of ecosystem instability.) * How much new code is replacing old code? (This might imply the language needs more bugfixes.)

Not sure what you mean. The Scala example looks nothing like the Clojure examples. The retention charts show you how much new code is replacing old code, and you can see the releases/rewrites as the code gets replaced.

The charts are very cool. But they’d be more informative if they tracked _interface_ changes. Maybe Scala is more flexible and the code changes are limited to optimizing the underlying implementation while keeping stable interfaces. It’s impossible to tell from the charts.

Re: Stability by Design

#24

Post by 0x1ceb00da » Fri, May 09, 2025, 4:39 AM UTC

raspasov wrote: post #14

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…

Sorry to hear that. Is it fair to assume that every individual library/API can somewhat easily create a brand-new-world with every release (because it won't compile until the types are "re-aligned") yet they don't bother to check if the new release works with any other library/API? I think the problem is partially cultural with a specific ecosystem but also fundamental. It takes a lot of type craft, care and creativi…

This is what you get if you start by making a library. First step should be making a program and once you have a fully functional, real world application, you should consider abstracting parts of it into a library.

Re: Stability by Design

#25

Post by jiehong » Fri, May 09, 2025, 5:03 AM UTC

ashishb wrote: post #13

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. That's true. However, you have now replaced the work of a compiler with testing.

Refactoring from a function returning a string to another returning a string, and all compiles, yet without tests nothing works in production because it’s not the same string.

On top of that, sometimes mocking in tests also hide the string breaking change you don’t yet know about.

On top of my head, I saw this happen with a base64 string padded vs unpadded, or emojis making their way through when they did not before, etc.

So yeah, the compiler tells you which pieces of your jigsaw apparently fit together, but tests show you if you get the right picture on the jigsaw at the end (or on some regions).

Re: Stability by Design

#26

Post by jiehong » Fri, May 09, 2025, 5:08 AM UTC

0xDEAFBEAD wrote: post #19

>For example, over its lifetime the Clojure community has shifted from accepting argument lists and named parameters in their functions to accepting a single hashmap. This is because the single hashmap is easier to grow over time. This seems a little nuts, to be honest. It feels like you're just pushing failures from easy-to-diagnose issues with the function signature, to hard-to-diagnose issues with the function bod…

I think it was meant from old style functions to new style, but not changing a given function’s signature this way.

Re: Stability by Design

#27

Post by lmm » Fri, May 09, 2025, 5:22 AM UTC

phoronixrly wrote: post #9

ashishb wrote: post #7

Earlier quoted context omitted.

> The outcome is the same, statically typed or dynamically. In both cases one need to perform refactoring in case of breaking changes. No. In statically typed languages, failures are usually caught in CI. In dynamically typed languages, they end up in production - https://github.com/pypa/setuptools/issues/4519

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.

Re: Stability by Design

#28

Post by eviks » Fri, May 09, 2025, 5:52 AM UTC

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…

> If I want the old solutions, that's what versioning is for. I'll use the old version.

And you'll miss all the stuff you do not want the old solution for. And all the old bugs

> faced with a dozen functions that all have similar but increasingly long names and do very similar things with subtle but likely important differences.

Unless all the old versions are marked add old/deprecated and can be hidden from your view. Then you only care about the old stuff if you used it before and don't want to change

Re: Stability by Design

#29

Post by asalahli » Fri, May 09, 2025, 5:53 AM UTC

> I selected the following libraries off the top of my head with three criteria: all have more than 500 stars and are in active use.

This sentence bothered me way more that it should've, for some reason.

Re: Stability by Design

#30

Post by codeflo » Fri, May 09, 2025, 5:56 AM UTC

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…

This is an issue that plagues modern open-source libraries in general, but the ones you mention, Winit and Wgpu, are particularly awful examples of this disease. Winit turning the event loop inside out might have had a reason on some platform, though I don't see why the old API couldn't have been supported anymore. Both projects frequently shuffle around their data structures with no rhyme or reason. Everything built on top of them breaks all the time, for tiny perceived gains in naming consistency. I think your suggested term "refuckering" is indeed a nice way to put it.