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

31–40 of 67 posts

Re: Stability by Design

#31

Post by MarkMarine »

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…

no, you pull out the things you need from the map in the function body and move forward. I recommend either reading up on how this works in Clojure or just trying it, it's pretty simple.

https://clojure.org/guides/destructuring#_associative_destru...

Some extra reading if you're curious: https://softwareengineering.stackexchange.com/questions/2723...

Re: Stability by Design

#32

Post by lelanthran »

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…

I think this is just the nature of Rust - everything needs to be specified upfront by the developer. Other languages are much more flexible in this regard.

It's also why we see so few original projects in Rust (compared to Go, etc), and so many rewrite-in-Rust projects: A rewrite of `ls` or `grep` is a project that has an engraved-in-stone requirement.

Creating an entire new project requires more flexibility as the requirements are only fully specified once some user feedback is in.

It would not be wise to choose Rust for something of an exploratory nature; anything original is going to be painful as large-scale refactors (which are a necessity in an original project) are going to be particularly painful.

Re: Stability by Design

#33

Post by boxed »

> I told Martin as much, and he agreed without hesitation that we needed to find a solution that didn't break current users' code. This is not a normal interaction amongst software engineers—a breed infamous for their long, drawn out debates on the most minute of details. However, this is absolutely expected in the Clojure community.

Well that's just slander as far as I'm concerned. Of course we other non-clojure programmers believe in backwards compatibility. What a crazy thing to suggest that we don't.

Re: Stability by Design

#34

Post by ogoffart »

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…

Just wanted to mention that Slint has had a stable API for over two years now. (We released Slint 1.0 more than two years ago and have kept things backward compatible since) So stable GUI APIs in Rust are possible. If you're looking for something solid to build on, Slint might be worth a look.

Re: Stability by Design

#35

Post by pier25 »

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 refuckering reminds me a lot of the JS ecosystem...

Re: Stability by Design

#36

Post by guappa »

codeflo wrote: post #30
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…

That's an issue on projects managed by inexperienced people. The license has little to do with this.

However I find that inexperienced people tend to coalesce around some languages rather than others.

Re: Stability by Design

#37

Post by raspasov »

0x1ceb00da wrote: post #24
raspasov wrote: post #14

Earlier quoted context omitted.

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.

I think most good libraries (regardless of language) are born out of a process like you described.

When I made the comment above, I assume a library has already passed that filter.

Re: Stability by Design

#38

Post by lelanthran »

> I told Martin as much, and he agreed without hesitation that we needed to find a solution that didn't break current users' code. This is not a normal interaction amongst software engineers

I find this to be extremely "it depends": this is a normal interaction amongst software engineers, if you have mature engineers.

It's only not normal in those ecosystems (Everyone knows which ones those are) which appear to have not had adults in the rooms during the design phase.

If you've only been developing for the last decade or so, you may think it's normal that stuff breaks all the time when software is upgraded. If you've been developing since the 90s you'd know that "upgrades brings breakage" is a new phenomenon, and the field (prior to 2014 or thereabouts) is filled with engineering compromises made purely to avoid breakage.

It's why, if I have an application from 10 years ago in React, I won't even try to build it again, but if I have an application from 1995 in C, it'll build just fine, dependencies included[1] (with pages of warnings, of course).

[1] C dependency graphs are small and shallow, because of the high friction in adding third-party libraries.

Re: Stability by Design

#39

Post by wereHamster »

lelanthran wrote: post #38

> I told Martin as much, and he agreed without hesitation that we needed to find a solution that didn't break current users' code. This is not a normal interaction amongst software engineers I find this to be extremely "it depends": this is a normal interaction amongst software engineers, if you have mature engineers. It's only not normal in those ecosystems (Everyone knows which ones those are) which appear to have…

To be fair, React itself has been exceptionally stable compared to the rest of the JavaScript / Node.js ecosystem. It's the other packages that are causing build failures, not React. Yes, React did deprecate and eventually remove some features, and those were real breaking changes. But it was at a far lower pace than every other package out there.

Re: Stability by Design

#40

Post by JackSlateur »

One great way to have stability is to rebase old code against new code

Say, you have the first function, with a specific signature and it does its stuff

Then later, you improve the stuff and the signature changes with a breaking change

Do not do that

Instead, create a new function (with a new signature) and push in it the whole code

And rewrite the old function to use your new function

This way, you keep one "production code": the new function. And you keep one interface-to-legacy code: the old function (which is nothing but a compatible gateway to the new function, and can be easily forgotten)

Old users have no breaking, new users have features, you keep a single code and are only burdened with a small compatible layer

Post reply on HN