3 ms·

I have a https://github.com/ghc-proposals/ghc-proposals/pull/351 https://github.com/ghc-proposals/ghc-proposals/pull/351 in the works for the stupid partiality

I have a https://github.com/ghc-proposals/ghc-proposals/pull/351 https://github.com/ghc-proposals/ghc-proposals/pull/351 in the works for the stupid partiality issue. As for the library ones: 1. Rust's std is better now, but will eventually sink to the level of base as ideoms improve because neither language has a good process for making breaking changes to the standard library 2. Rust has the core---std split, which Haskell desperately needs. Vector absolutely should be a separate package, but just the way alloc and hashbrown are separate packages in Rust land. Trying to work on that too. Now that Michael Snoyman thinks that exceptions in pure code are bad, and likes Rust, I wish he would think that exceptions in IO code are also bad, and we should use more EitherT like Rust.

ragnese 6y ago
Yeah. Rust's standard library already has cruft (e.g., std::error::Error deprecations), and some potential sore spots (no custom allocators, Pin/Promise unsoundness: https://internals.rust-lang.org/t/unsoundness-in-pin/11311 https://internals.rust-lang.org/t/unsoundness-in-pin/11311). I do wonder if there's some way to hide parts of the standard library with the Rust "edition" mechanism. It'll stay there, technically, for backwards compatibility, but any one who opts in to the new edition wouldn't see deprecated stuff exported from the std prelude.
- nynx 6y ago
  Custom allocators are coming soon.
  - ragnese 6y ago
    Right, but there was some frustration expressed in the discussions (IIRC) because you can't break backwards compat. So you can't just pass in an allocator to functions that might allocate. I don't have any skin in the game and don't really care how custom allocators will work (I'm glad the feature will exist, though).
- Ar-Curunir 6y ago
  > I do wonder if there's some way to hide parts of the standard library with the Rust "edition" mechanism. It'll stay there, technically, for backwards compatibility, but any one who opts in to the new edition wouldn't see deprecated stuff exported from the std prelude. Maybe in the future one could introduce pub(< ed2018) to indicate that an item is available only before edition 2018
  - steveklabnik 6y ago
    This has been discussed, but it's got pros and cons, and is semi-controversial. We'll see.
    - Ar-Curunir 6y ago
      Right, that’s what folks said the last time I asked about it. That’s why I put a maybe there :P
- kibwen 6y ago
  > Pin/Promise unsoundness Note that there was only a brief window between the bug there being reported and the fix landing. These days the only way to exploit any unsoundness there is via using unstable features, and as long as there's a soundness exploit those features certainly won't be stabilized.
  - ragnese 6y ago
    Thank goodness. I didn't realize that the unsoundness was now contained to unstable features.
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...

ragnese 6y ago

Yeah. Rust's standard library already has cruft (e.g., std::error::Error deprecations), and some potential sore spots (no custom allocators, Pin/Promise unsoundness: https://internals.rust-lang.org/t/unsoundness-in-pin/11311 https://internals.rust-lang.org/t/unsoundness-in-pin/11311). I do wonder if there's some way to hide parts of the standard library with the Rust "edition" mechanism. It'll stay there, technically, for backwards compatibility, but any one who opts in to the new edition wouldn't see deprecated stuff exported from the std prelude.

nynx 6y ago
Custom allocators are coming soon.
- ragnese 6y ago
  Right, but there was some frustration expressed in the discussions (IIRC) because you can't break backwards compat. So you can't just pass in an allocator to functions that might allocate. I don't have any skin in the game and don't really care how custom allocators will work (I'm glad the feature will exist, though).
Ar-Curunir 6y ago
> I do wonder if there's some way to hide parts of the standard library with the Rust "edition" mechanism. It'll stay there, technically, for backwards compatibility, but any one who opts in to the new edition wouldn't see deprecated stuff exported from the std prelude. Maybe in the future one could introduce pub(< ed2018) to indicate that an item is available only before edition 2018
- steveklabnik 6y ago
  This has been discussed, but it's got pros and cons, and is semi-controversial. We'll see.
  - Ar-Curunir 6y ago
    Right, that’s what folks said the last time I asked about it. That’s why I put a maybe there :P
kibwen 6y ago
> Pin/Promise unsoundness Note that there was only a brief window between the bug there being reported and the fix landing. These days the only way to exploit any unsoundness there is via using unstable features, and as long as there's a soundness exploit those features certainly won't be stabilized.
- ragnese 6y ago
  Thank goodness. I didn't realize that the unsoundness was now contained to unstable features.

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...