6 ms·

> neither language has a good process for making breaking changes to the standard library What language/ecosystem in your opinion does have a good process for

by tomp 6y ago

> neither language has a good process for making breaking changes to the standard library What language/ecosystem in your opinion does have a good process for making breaking changes? I'm curious as that's what I see one of the main remaining problems of language design, I don't really see any viable solutions but if there are some, I'd love to learn about them!

Ericson2314 6y ago
The solution is simple: Don't have standard libraries! The compile repository should just contain the absolute bare minimum of primops and what not, regular libraries should do the rest. Yes there should be a batteries-included starter pack, and it can be bigger than most standard libraries even, but it should be maintained separately. Ironically, C, with it's terrible stdlib, gets this right. Neither GCC or Clang is in the business of maintaining libcs. C does this for Conway's law reasons with kernel vs compiler competing for ownership, but still, it's a good result. People squirm at the thought of this. I think the issue is not that this is inherently bad UX, but that Cargo/Cabal/etc. are simply too shitty. I think people's expectations of those tools is too low, and if those are fixed, this problems with this will evaporate.
- tomp 6y ago
  Ok, I understand your proposal. It definitely makes sense from the language evolution perspective, although to some degree it's a cop-out - codebases can still be stuck on an old version (of the non-standard lib) and have difficulties upgrading. I use Python for my day job, and the experience there is illustrative - it has a stdlib which I will use with very strong preference, except extremely good non-standard libraries (e.g. numpy and requests). The ecosystem can still get stuck on that (2-to-3 transition was painful partially because of ascii/unicode distinction, and partially because of numpy taking time to migrate). But in principle I agree! Disentangling language/compiler from stdlib is strictly better, as it allows the free market to take over, competition to flourish, and people to "vote with their feet". > inherently bad UX, but that Cargo/Cabal/etc. are simply too shitty More strong opinions :) I like that! What are some examples of good package managers in your opinion? Some people praise Node/NPM, and I'm personally quite happy with conda for Python, but then my needs are fairly vanilla and even I can see some pretty obvious improvements...
  - lmm 6y ago
    > I use Python for my day job, and the experience there is illustrative - it has a stdlib which I will use with very strong preference, except extremely good non-standard libraries (e.g. numpy and requests). The ecosystem can still get stuck on that (2-to-3 transition was painful partially because of ascii/unicode distinction, and partially because of numpy taking time to migrate). I think this is a problem of Python a) having extremely poor dependency management and b) consequently favouring large frameworks. It's hard to migrate something the size of numpy from Python 2 to 3 in one go, but since it's a single giant library they didn't have any choice.
- Ar-Curunir 6y ago
  Doesn’t Rust mark deprecated functions as, wel, deprecated? Also, the edition system (with some small extensions) in theory enables removing stuff from future editions Finally, there is incredible value in sharing common vocabulary for some core objects like basic data structures
  - steveklabnik 6y ago
    > Doesn’t Rust mark deprecated functions as, wel, deprecated? Yes. > Also, the edition system (with some small extensions) in theory enables removing stuff from future editions In the language, but not the standard library.
- nindalf 6y ago
  Could you mention what you're lacking in cargo? Feel like it's not lacking in any features, and it's really easy to create plug ins for new functionality. If your issue is that the Rust standard library is too large, that's not a view I've ever heard before. What I hear consistently is that packages that could be in the stdlib like serde, rand, regex are crates pulled in by cargo.
- sweeneyrod 6y ago
  OCaml does this and it's moderately annoying.
xiphias2 6y ago
Rust is making breaking changes in the language (called editions), but different versions of the language can use each other as libraries. They use a common IR format, just like languages targeting the same VM.
- Ericson2314 6y ago
  editions sharing std good, but that also means this doesn't help with the need to change std at all. You have to design the institutions assume you will constantly be making mistakes and they will accumulate. Wishing away braking changes is like pretending buildings don't need vacuuming and dusting. The second law of thermodynamics would like a word with you.
nlitened 6y ago
I like Clojure's process: thoughtfully design things to be simple, then commit to never breaking compatibility. It works amazingly well from what I can tell.
- Kototama 6y ago
  It's amazing and I love the language but I also did not see any great innovations around Clojure in the last years, after ClojureScript for example.
  - nlitened 6y ago
    That is true for me as well. Every year I quietly hope that Rich Hickey will soon reveal a new breakthrough. On the other hand, all the “new hot” features in many other languages have mostly been available as libraries in Clojure for a long time — there’s nothing specific so far that I strongly wish existed.

by tomp 6y ago

Ericson2314 6y ago

The solution is simple: Don't have standard libraries! The compile repository should just contain the absolute bare minimum of primops and what not, regular libraries should do the rest. Yes there should be a batteries-included starter pack, and it can be bigger than most standard libraries even, but it should be maintained separately. Ironically, C, with it's terrible stdlib, gets this right. Neither GCC or Clang is in the business of maintaining libcs. C does this for Conway's law reasons with kernel vs compiler competing for ownership, but still, it's a good result. People squirm at the thought of this. I think the issue is not that this is inherently bad UX, but that Cargo/Cabal/etc. are simply too shitty. I think people's expectations of those tools is too low, and if those are fixed, this problems with this will evaporate.

tomp 6y ago
Ok, I understand your proposal. It definitely makes sense from the language evolution perspective, although to some degree it's a cop-out - codebases can still be stuck on an old version (of the non-standard lib) and have difficulties upgrading. I use Python for my day job, and the experience there is illustrative - it has a stdlib which I will use with very strong preference, except extremely good non-standard libraries (e.g. numpy and requests). The ecosystem can still get stuck on that (2-to-3 transition was painful partially because of ascii/unicode distinction, and partially because of numpy taking time to migrate). But in principle I agree! Disentangling language/compiler from stdlib is strictly better, as it allows the free market to take over, competition to flourish, and people to "vote with their feet". > inherently bad UX, but that Cargo/Cabal/etc. are simply too shitty More strong opinions :) I like that! What are some examples of good package managers in your opinion? Some people praise Node/NPM, and I'm personally quite happy with conda for Python, but then my needs are fairly vanilla and even I can see some pretty obvious improvements...
- lmm 6y ago
  > I use Python for my day job, and the experience there is illustrative - it has a stdlib which I will use with very strong preference, except extremely good non-standard libraries (e.g. numpy and requests). The ecosystem can still get stuck on that (2-to-3 transition was painful partially because of ascii/unicode distinction, and partially because of numpy taking time to migrate). I think this is a problem of Python a) having extremely poor dependency management and b) consequently favouring large frameworks. It's hard to migrate something the size of numpy from Python 2 to 3 in one go, but since it's a single giant library they didn't have any choice.
Ar-Curunir 6y ago
Doesn’t Rust mark deprecated functions as, wel, deprecated? Also, the edition system (with some small extensions) in theory enables removing stuff from future editions Finally, there is incredible value in sharing common vocabulary for some core objects like basic data structures
- steveklabnik 6y ago
  > Doesn’t Rust mark deprecated functions as, wel, deprecated? Yes. > Also, the edition system (with some small extensions) in theory enables removing stuff from future editions In the language, but not the standard library.
nindalf 6y ago
Could you mention what you're lacking in cargo? Feel like it's not lacking in any features, and it's really easy to create plug ins for new functionality. If your issue is that the Rust standard library is too large, that's not a view I've ever heard before. What I hear consistently is that packages that could be in the stdlib like serde, rand, regex are crates pulled in by cargo.
sweeneyrod 6y ago
OCaml does this and it's moderately annoying.

xiphias2 6y ago

Rust is making breaking changes in the language (called editions), but different versions of the language can use each other as libraries. They use a common IR format, just like languages targeting the same VM.

Ericson2314 6y ago
editions sharing std good, but that also means this doesn't help with the need to change std at all. You have to design the institutions assume you will constantly be making mistakes and they will accumulate. Wishing away braking changes is like pretending buildings don't need vacuuming and dusting. The second law of thermodynamics would like a word with you.

nlitened 6y ago

I like Clojure's process: thoughtfully design things to be simple, then commit to never breaking compatibility. It works amazingly well from what I can tell.

Kototama 6y ago
It's amazing and I love the language but I also did not see any great innovations around Clojure in the last years, after ClojureScript for example.
- nlitened 6y ago
  That is true for me as well. Every year I quietly hope that Rich Hickey will soon reveal a new breakthrough. On the other hand, all the “new hot” features in many other languages have mostly been available as libraries in Clojure for a long time — there’s nothing specific so far that I strongly wish existed.