Follow up: the Rust Platform

[yigal100]

@brson

This is one avenue yeah, but even if we go this sort of minimal, interface-heavy route, I am always inclined not to literally put (big) new things directly in std. For example, I don't want anything related to databases in std. If we were to define e.g. an ODBC-like interface for Rust and distribute it to everyone, I would want it in a different crate. At the same time, the way we distribute std is basically an artifact of its development process and that it has unstable hooks directly into the compiler. Any crates 'above' std I strongly prefer to distribute through our standard mechanism (cargo).

I totally agree and it was the whole premise of my comment that the stdlib should remain as minimal as it is today.

All I'm saying is that if we want to have an endorsed official "Rust Platform" meta-package than it should contain at most the standardized APIs & interfaces.
Actually, I'd go further and suggest that we have an entire set of such officially endorsed meta-packages, each standardizes a specific area. So e.g. we could have the "Rust-DB" cargo meta-package that defines the official ODBC-like API.

[wuranbo]

Support! Rust is already not easy to docile. Let the platform gives enough sugar to enough people to have a “chemical reaction”. Very wanting to see more people focus on a smaller group of libs, then shows me more some kind of “standard answer” and more active and more useful discusses on the simliar problem. People need have enough talkings, then go to deeper talking. And I think it’s a tradeoff should be done right now. I think Rust must have some “killer framework” or “killer application” in three years to have a big step forward, and I think together people to “Rust Platform” is good to achieve it. Then when Rust go more futher, Rust have time to fix the disadvantage of this choice.

[jxn]

As a first step towards discoverability and blessed-packages, don’t underestimate the value of an opt-in from package managers. If, for instance, a package owner at crates.io has the ability to tag their package as a platform-candidate or non-platform-candidate, this might take care of some of the work.

I have a number of packages in another language’s shared package ecosystem. Most, I have added because I think there’s a chance they could be helpful to others and there were no appropriate alternatives at the time, but I wouldn’t want most of my packages in a “platform” if I could avoid it.

[indolering]

I really like how the Rust Platform is attempting to strike a balance between ad-hoc community libraries and pushing everything into the standard library. I think a lot of this criticism coming out of the resultant big/small standard library debate has to do with worries that this is an excuse for the standard library to stagnate. As much as we all hate it when a shitty API makes it into the standard library, we also hate it when incompatible APIs fracture the ecosystem up unnecessarily.

[brson]

@jxn

I have a number of packages in another language's shared package ecosystem. Most, I have added because I think there's a chance they could be helpful to others and there were no appropriate alternatives at the time, but I wouldn't want most of my packages in a "platform" if I could avoid it.

Good perspective. There are some considerable downsides to having your work pulled into the official distribution for sure, including stagnation, loss of control, increased maintainership responsibilities.

[donaldpipowitch]

Thank you for collecting the feedback!

@aturon

Let's start with lower-hanging fruit.

I especially love this part. If discoverability, integration, or quality can become better by using/enhancing Cargo that would be great! For someone who is new to the language it would be great if crates in Cargo could be flagged as something like "curated"/"blessed"/"de-facto standard" by a group of core community members. That would help a lot. Maybe this flagging could be evaluated again after x-months, so they are up to date.

[sgrif]

I mean, someone has to care.

Sure, but why can't that someone be a third party glue crate? I'd like to be able to have a chrono_diesel crate exist completely independently in the ecosystem.

Like always, I think modifying the coherence rules to enable more blanket impls is the solution here. We should have a base library (std presumably) defining the trait DateTime

I think the problem quickly becomes more general than what the standard library should be expected to cover. Take UUID as another example.

[withoutboats]

@sgrif

Sure, but why can't that someone be a third party glue crate? I'd like to be able to have a chrono_diesel crate exist completely independently in the ecosystem.

You'll have to provide a way to adjudicate who is allowed to be the glue crate that guarantees there can only be one such crate. I don't know of any way other than the way we have now - 'one of the two crates involved depends on the other one and provides the impls.'

Consider the case in which two different chrono_serde and serde_chrono crates are uploaded to crates.io, and both become popular in the ecosystem. Both provide an impl Serialize for DateTime. The types in these impls are identical, there's no way to make them coherent. These crates present a hard split in the ecosystem - my dependency tree cannot include both of them. Every time someone provides an orphan impl, it represents a potential hard split in the ecosystem. This is so much worse than what we have now.

There are three properties it would be desirable for the language to have, and you get to choose two:

• Impls do not need to be specifically imported (e.g. you only need to have Extend and HashMap in scope to merge two hashmaps, you don't also need to import the specific impl block).
• When you build any two libraries together, you do not get coherence errors.
• Anyone can implement any trait for any type.

Rust chose the first two. We could consider dropping the second for the third, but I think the second is clearly superior to the third.

@sgrif

I think the problem quickly becomes more general than what the standard library should be expected to cover. Take UUID as another example.

This is definitely true, but we're up against like the fundamental laws of information theory or something, so all we can do is find ways to mitigate it.

[dbrgn]

I didn’t completely read this thread, but regarding the “Improving discoverability” part we could take some inspiration from https://djangopackages.org/. It helps a lot when choosing libraries for certain areas.

[oli-obk]

please continue the discussion on orphan impls in Vague proposal: Extending coherence with workspaces

I don’t think it’s relevant here, and there’s been a lot of discussion in the other thread.

[wuranbo]

@aturon https://www.infoq.com/news/2016/08/scala-development-is-heating-up , at the botom of the article, Scala may will split the stdlib to core and platform ~~~~