Hacker News Reader

Comment by Ericson2314 | Hacker News Reader

I have a 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.

View on HN

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

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.

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

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

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

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

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.

OCaml does this and it's moderately annoying.

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.

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.

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.

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.

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.

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

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.

Custom allocators are coming soon.

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

> 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

This has been discussed, but it's got pros and cons, and is semi-controversial. We'll see.

Right, that’s what folks said the last time I asked about it. That’s why I put a maybe there :P

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

Thank goodness. I didn't realize that the unsoundness was now contained to unstable features.

Reply on news.ycombinator.com