51–60 of 67 posts
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…
> 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.
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.)
> 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.
One of the first things I learned when I started shipping APIs and software packages is that the behavior you expose and the interface you provide for it have to be written in stone. The alternative is to break code and other packages that depend on it. Your package's changes are always somebody else's bugs. Compile-time errors and static analysis provide helpful guarantees and reduce suffering, but that doesn't change the fact that when you introduce changes you're still throwing Legos on the floor of someone's bedroom while they sleep.
Major-version revisions by definition allow for breaking changes, but a breaking change needs strong justification: either you know nobody or few users are using what you've changed, or there's broad consensus that there's a bug (but one that didn't need to be fixed with a minor-version update, so it's probably a design problem, not a code bug), or the people using it broadly agree on the need for or benefit of the change.
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).
Will also keep in mind that tests are optional. This is def. a healthy mindset.
Earlier quoted context omitted.
> 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).
I will keep in mind for future projects that you don't need tests in compiled languages because the compiler does it for you. Will also keep in mind that tests are optional. This is def. a healthy mindset.
who said that?
> Will also keep in mind that tests are optional. This is def. a healthy mindset.
Once again, I have to ask - where did you get that from?
Too much horizontal striping in this kind of graph can be bad news: the project isn't improving its old code. That could be because the code is perfect and doesn't need anything, or it could be that the maintainers are not confident enough to touch it.
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…
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…