Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rust Platform

aturon.github.io

Post reply on HN
Print view View original

11–20 of 256 posts

Re: The Rust Platform

#11

Post by coolsunglasses »

steveklabnik wrote: post #6
coolsunglasses wrote: post #2

Haskell Platform is the last thing you should take inspiration from. Many of us have been doing our best to kill it off. Maybe the downsides involved wouldn't affect Rust in the same ways. My suggestion, look at how Stack (the tool) and Stackage (the platform) work: https://docs.haskellstack.org/en/stable/README/ https://github.com/commercialhaskell/stack https://www.stackage.org/

I actually cross-posted this to /r/haskell to get explicit feedback. Someone else mentioned stack/stackage. In my understanding, Cargo already does this specific behavior. Can anyone who's more familiar with both confirm this?

I checked that other thread, I agree completely with jeremyjh's summary.

The problem with Haskell Platform came down to a set of intersecting issues:

- A culture of setting very strict & narrow version bounds. (Based on known-good rather than based on avoiding known-broken)

- Tools (Cabal) that enforce dependency version bounds. If there's mutual/transitive incompatibiltiy in version bounds - the build fails, period. You had to figure out the problem and fix it yourself if there was a truly irreconcilable issue.

- Recommended installer on the website (Platform) was unnecessarily installing packages into the global package database, making you "stuck" with those versions for _all_ packages you attempted to build. Cabal was restricted to finding builds that abide by dependency versions narrowed to the ones provided by the global package database.

These problems led to beginners being confused by seemingly spurious build failures because Platform would fall out of date with the rest of the ecosystem. Cabal would be unable to find sets of compatible dependencies and say it couldn't build the package.

What non-beginners were doing to avoid these problems was:

1. Install the bare compiler, no Platform

2. Use package database sandboxes for each project

All of these (UX and technical) problems were solved without compromising dependency conflict enforcement via Stackage and Stack.

Speaking hypothetically, if Cargo behaves like Maven or Ivy and pulls in two dependencies who want conflicting versions (1.1 and 1.2, say) of a particular library and just picks a winner, then you'll never see something like this.

Re: The Rust Platform

#12

Post by steveklabnik »

coolsunglasses wrote: post #11
steveklabnik wrote: post #6

Earlier quoted context omitted.

I actually cross-posted this to /r/haskell to get explicit feedback. Someone else mentioned stack/stackage. In my understanding, Cargo already does this specific behavior. Can anyone who's more familiar with both confirm this?

I checked that other thread, I agree completely with jeremyjh's summary. The problem with Haskell Platform came down to a set of intersecting issues: - A culture of setting very strict & narrow version bounds. (Based on known-good rather than based on avoiding known-broken) - Tools (Cabal) that enforce dependency version bounds. If there's mutual/transitive incompatibiltiy in version bounds - the build fails, period.…

Cargo will do its best to unify separate versions, but if it can't, then it will just include both. So it sounds like this would be a non-issue here.

Re: The Rust Platform

#13

Post by qwertyuiop924 »

Good work! The idea of dropping extern crate is worrying, however. Most of the ways that that would be done would add more irregularity, complexity, and implied environment to the language (Rust Platform is always there, whether or not you want it), all of which are opportunities for bugs to creep into code.

Re: The Rust Platform

#14

Post by steveklabnik »

qwertyuiop924 wrote: post #13

Good work! The idea of dropping extern crate is worrying, however. Most of the ways that that would be done would add more irregularity, complexity, and implied environment to the language (Rust Platform is always there, whether or not you want it), all of which are opportunities for bugs to creep into code.

What worries you about dropping extern crate? A lot of people feel like it's duplicating what's in your Cargo.toml anyway.

Re: The Rust Platform

#15

Post by Ericson2314 »

dikaiosune wrote: post #9
coolsunglasses wrote: post #5

Earlier quoted context omitted.

This is the main thing I've written publicly on it: https://mail.haskell.org/pipermail/haskell-community/2015-Se... My email is what finally moved the committee and GHC devs on including Stack with the Platform and on some other decisions concerning the website. Like I said, not all the downsides may be applicable to how Cargo works or what aturon has in mind, but please don't cite it as an exemplar of anything.

That's quite the email! Without a TLDR, I'm not sure how to assess how susceptible Cargo is to those problems. My personal experience with Rust has been that there are very few instances where versioning or dependency issues cause me problems. The specific instances I have dealt with would be resolved by the proposal in the blog post (trying to use a version of serde which differs from what another core-ish library w…

IMO the root problem is that the Haskell Platform is both a set of curated packages and a bandaid for the fact that so many things Haskell are hard to build/install for no-good reason.

On the first front I guess it's alright (but stackage is better) and on the second front it's totally inadequate—maybe even harmful in that it probably made the problem just less painful enough to spur procrastination.

I think most of this lesson doesn't apply to rust, but still good to be aware. It certainly gave me a strong eversion to course-grained dependency management as a bandaid.

Re: The Rust Platform

#16

Post by coolsunglasses »

steveklabnik wrote: post #12
coolsunglasses wrote: post #11

Earlier quoted context omitted.

I checked that other thread, I agree completely with jeremyjh's summary. The problem with Haskell Platform came down to a set of intersecting issues: - A culture of setting very strict & narrow version bounds. (Based on known-good rather than based on avoiding known-broken) - Tools (Cabal) that enforce dependency version bounds. If there's mutual/transitive incompatibiltiy in version bounds - the build fails, period.…

Cargo will do its best to unify separate versions, but if it can't, then it will just include both. So it sounds like this would be a non-issue here.

>So it sounds like this would be a non-issue here.

In the sense of being a sucking chest wound driving new people away, I agree.

>just include both

makes my guts wrench a bit though. I understand how you're (currently) getting away with it but yikes.

Re: The Rust Platform

#17

Post by Animats »

I'm a bit worried when a language develops a "platform" and an "ecosystem". This usually means you need to bring in a large amount of vaguely relevant stuff to do anything. It adds another layer of cruft, and more dependencies.

Write standalone tools, but don't create a "platform". Don't make the use of the language dependent on your tools.

C++ does not have a "platform". Nor does it need one.

Re: The Rust Platform

#18

Post by coolsunglasses »

Ericson2314 wrote: post #15
dikaiosune wrote: post #9

Earlier quoted context omitted.

That's quite the email! Without a TLDR, I'm not sure how to assess how susceptible Cargo is to those problems. My personal experience with Rust has been that there are very few instances where versioning or dependency issues cause me problems. The specific instances I have dealt with would be resolved by the proposal in the blog post (trying to use a version of serde which differs from what another core-ish library w…

IMO the root problem is that the Haskell Platform is both a set of curated packages and a bandaid for the fact that so many things Haskell are hard to build/install for no-good reason. On the first front I guess it's alright (but stackage is better) and on the second front it's totally inadequate—maybe even harmful in that it probably made the problem just less painful enough to spur procrastination. I think most of…

>so many things Haskell are hard to build/install for no-good reason.

Were. Were hard. It's quite fine now with Stack. I know users of all kinds of languages that all miss Stack when they're working on their non-Haskell projects.

Re: The Rust Platform

#19

Post by steveklabnik »

coolsunglasses wrote: post #16
steveklabnik wrote: post #12

Earlier quoted context omitted.

Cargo will do its best to unify separate versions, but if it can't, then it will just include both. So it sounds like this would be a non-issue here.

>So it sounds like this would be a non-issue here. In the sense of being a sucking chest wound driving new people away, I agree. >just include both makes my guts wrench a bit though. I understand how you're (currently) getting away with it but yikes.

Why would it drive people away? I read your thesis as "it's broken all the time so people don't like it", but I'm saying that it wouldn't be broken.

EDIT: Apparently coolsunglasses was referring to the Platform, not Cargo, with this comment.

Re: The Rust Platform

#20

Post by eridius »

Animats wrote: post #17

I'm a bit worried when a language develops a "platform" and an "ecosystem". This usually means you need to bring in a large amount of vaguely relevant stuff to do anything. It adds another layer of cruft, and more dependencies. Write standalone tools, but don't create a "platform". Don't make the use of the language dependent on your tools. C++ does not have a "platform". Nor does it need one.

I get the feeling that you didn't really read the post. Nothing in the platform is required to use Rust, and you can trivially write Rust packages that don't use the platform. The point of the platform is for convenience. In most cases it will make sense to use it because it provides a convenient set of libraries that are known to work well together, but you could also choose to just ignore the Rust platform entirely and continue to use Rust the same way we've been using it up to now.
Post reply on HN