4 ms·

> These crates also get "refactored" every few months, with breaking API changes I am dealing with similar issues in npm now, as someone who is touching Node d

> These crates also get "refactored" every few months, with breaking API changes I am dealing with similar issues in npm now, as someone who is touching Node dev again. The number of deprecations drives me nuts. Seems like I’m on a treadmill of updating APIs just to have the same functionality as before.

harles 2y ago
I’ve found such changes can actually be a draw at first. “Hey look, progress and activity!”. Doubly so as a primarily C++ dev frustrated with legacy choices in stl. But as you and others point out, living with these changes is a huge pain.
- bigfatfrock 2y ago
  If only middle management and project managers the world over had such a positive perspective!
schneems 2y ago
I wish for ecosystems that would let maintainers ship deprecations with auto-fixing lint rules.
- twic 2y ago
  In the Java universe, there is OpenRewrite for this: https://github.com/openrewrite/rewrite https://github.com/openrewrite/rewrite eg: https://docs.openrewrite.org/recipes/java/migrate/joda/jodatimerecipe https://docs.openrewrite.org/recipes/java/migrate/joda/jodat... I occasionally notice libraries or frameworks including OpenRewrite rules in their releases. I've never tried it, though!
- photonthug 2y ago
  Yeah, not only is the structure of business workflows often resistant to mature software dev workflows, developers themselves increasingly lack the discipline, skills or interest in backwards compatibility or good initial designs anyway. Add to this the trend that fast changing software is actually a decent strategy to keep LLMs befuddled, and it’s probably going to become an unofficial standard to maintain support contracts. On that subject, ironically code gen by ai for ai related work is often least reliable due to fast churn. Langchain is a good example of this and also kind of funny, they suggest / integrate gritql for deterministic code transforms rather than using AI directly: https://python.langchain.com/docs/versions/v0_3/ https://python.langchain.com/docs/versions/v0_3/. Overall.. mastering things like gritql, ast grep, and CST tools for code transforms still pays off. For large code bases, No matter how good AI gets, it is probably better to get them to use formal/deterministic tools like these rather than trust them with code transformations more directly and just hope for the best..
  - jwhitlark 1y ago
    https://github.com/clj-commons/rewrite-clj https://github.com/clj-commons/rewrite-clj is an absolute superpower for this kind of thing, if you were using Clojure. It always saddened me it doesn't get more exposure. As good as Rust is, I still feel there needs to be a "high-low" strategy for most biz/game code. You want to be able to depend on your low level abstractions, while constantly changing up how you fit them together.
- wolvesechoes 2y ago
  Modelica, which is a DSL for modelling DAE systems, has a facility of automated conversions. You can provide a script that automatically modifies user's code then they upgrade to newer version of your lib, or prints the message if automatic migration is not possible. It is very strange that more mainstream languages do not have such features (and I am not talking about 3rd party tools; in Modelica conversions are part of the language spec).
- mike_hearn 2y ago
  Kotlin has some limited support for that: @Deprecated(replaceWith = "new expression") Only works for simple cases but better than nothing. For more, there's OpenRewrite.
- quotemstr 2y ago
  They do. They're called stable, versioned interfaces and work in any language
christophilus 2y ago
I’ve found the key to the JS ecosystem is to be very picky about what dependencies you use. I’ve got a number of vanilla Bun projects that only depend on TypeScript (and that is only a dev dependency). It’s not always possible to be so minimal, but I view every dependency as lugging around a huge lurking liability, so the benefit it brings had better far outweigh that big liability. So far, I’ve only had one painful dependency upgrade in 5 years, and that was Tailwind 3-4. It wasn’t too painful, but it was painful enough to make me glad it’s not a regular occurrence.
- whstl 2y ago
  I'm finding most of the modern React ecosystem to be made of liabilities. The constant update cycles of some libraries (hello Router) is problematic in itself, but there's too many fashionable things that sound very good in theory but end up being a huge problem when used in fast-moving projects, like headless UI libraries.
- wolvesechoes 2y ago
  "I’ve found the key to the JS ecosystem is to be very picky about what dependencies you use" Well, I always thought it is the key in every kind of development, JS or else.
molszanski 2y ago
Hmmm.. strange. Don’t have issues like that. Can you show us your package json?
lostb1t 2y ago
the Js ecosystem is by far the worst offender in this area

harles 2y ago

I’ve found such changes can actually be a draw at first. “Hey look, progress and activity!”. Doubly so as a primarily C++ dev frustrated with legacy choices in stl. But as you and others point out, living with these changes is a huge pain.

bigfatfrock 2y ago
If only middle management and project managers the world over had such a positive perspective!

schneems 2y ago

I wish for ecosystems that would let maintainers ship deprecations with auto-fixing lint rules.

twic 2y ago
In the Java universe, there is OpenRewrite for this: https://github.com/openrewrite/rewrite https://github.com/openrewrite/rewrite eg: https://docs.openrewrite.org/recipes/java/migrate/joda/jodatimerecipe https://docs.openrewrite.org/recipes/java/migrate/joda/jodat... I occasionally notice libraries or frameworks including OpenRewrite rules in their releases. I've never tried it, though!
photonthug 2y ago
Yeah, not only is the structure of business workflows often resistant to mature software dev workflows, developers themselves increasingly lack the discipline, skills or interest in backwards compatibility or good initial designs anyway. Add to this the trend that fast changing software is actually a decent strategy to keep LLMs befuddled, and it’s probably going to become an unofficial standard to maintain support contracts. On that subject, ironically code gen by ai for ai related work is often least reliable due to fast churn. Langchain is a good example of this and also kind of funny, they suggest / integrate gritql for deterministic code transforms rather than using AI directly: https://python.langchain.com/docs/versions/v0_3/ https://python.langchain.com/docs/versions/v0_3/. Overall.. mastering things like gritql, ast grep, and CST tools for code transforms still pays off. For large code bases, No matter how good AI gets, it is probably better to get them to use formal/deterministic tools like these rather than trust them with code transformations more directly and just hope for the best..
- jwhitlark 1y ago
  https://github.com/clj-commons/rewrite-clj https://github.com/clj-commons/rewrite-clj is an absolute superpower for this kind of thing, if you were using Clojure. It always saddened me it doesn't get more exposure. As good as Rust is, I still feel there needs to be a "high-low" strategy for most biz/game code. You want to be able to depend on your low level abstractions, while constantly changing up how you fit them together.
wolvesechoes 2y ago
Modelica, which is a DSL for modelling DAE systems, has a facility of automated conversions. You can provide a script that automatically modifies user's code then they upgrade to newer version of your lib, or prints the message if automatic migration is not possible. It is very strange that more mainstream languages do not have such features (and I am not talking about 3rd party tools; in Modelica conversions are part of the language spec).
mike_hearn 2y ago
Kotlin has some limited support for that: @Deprecated(replaceWith = "new expression") Only works for simple cases but better than nothing. For more, there's OpenRewrite.
quotemstr 2y ago
They do. They're called stable, versioned interfaces and work in any language

christophilus 2y ago

I’ve found the key to the JS ecosystem is to be very picky about what dependencies you use. I’ve got a number of vanilla Bun projects that only depend on TypeScript (and that is only a dev dependency). It’s not always possible to be so minimal, but I view every dependency as lugging around a huge lurking liability, so the benefit it brings had better far outweigh that big liability. So far, I’ve only had one painful dependency upgrade in 5 years, and that was Tailwind 3-4. It wasn’t too painful, but it was painful enough to make me glad it’s not a regular occurrence.

whstl 2y ago
I'm finding most of the modern React ecosystem to be made of liabilities. The constant update cycles of some libraries (hello Router) is problematic in itself, but there's too many fashionable things that sound very good in theory but end up being a huge problem when used in fast-moving projects, like headless UI libraries.
wolvesechoes 2y ago
"I’ve found the key to the JS ecosystem is to be very picky about what dependencies you use" Well, I always thought it is the key in every kind of development, JS or else.

molszanski 2y ago

Hmmm.. strange. Don’t have issues like that. Can you show us your package json?

lostb1t 2y ago

the Js ecosystem is by far the worst offender in this area