undefined | Better HN

0 pointsstaticassertion7y ago0 comments

Why choose a winner?

What if a 'winner' today is a loser in a year? What if we come up with a new approach to solving a problem that requires a breaking change, or a new crate?

Would someone be inclined to try to improve the state of HTTP given a good enough version in std? Would we be ok with discouraging that sort of competitive approach?

To be honest, all I see are downsides to having a huge std lib. The benefit seems to be that there isn't an obvious, de facto choice for what crates to use. But I think that's a problem better solved by crates.io.

0 comments

dikaiosune7y ago

I tend to agree, but I also think that there's a little bit of nuance here. For one thing, I have definitely enjoyed using a large standard library...when I didn't have access to cargo or tools of similar quality.

My impression is that many of those who are asking for Rust's stdlib to grow are also/actually asking "please make it really easy for me to use these APIs that I care about," to which I would respond "it's OK, code can be easy to reuse even if it's not in the stdlib," "try cargo," and "crates.io needs to continue improving on discoverability."

EDIT: also, hi!

galangalalgol7y ago

To make it into some industries it needs to also be easy to grab a snapshot of all the batteries and do mods and licensing checks/approvals before doing a network unconnected install. Running a crates clone may or may not make sense. For some cases grabby an image on a thumb drive or DVD and doing a standalone install on a single machine makes sense.

staticassertionOP7y ago

Hiiii.

I think we're likely on the same page. The desire to make writing an HTTP server that much easier by providing a quick-to-use solution is entirely reasonable.

I just don't believe the solution is some 'sanctioned', permanent addition to std.

Better to be solved in crates.io.

beefsack7y ago

Perhaps a better idea might be to include the most popular client in some form of official tutorial / guide / documentation, or as part of some extended documentation separate to the language doc?

That way libraries can coexist, but new developers have a single doc location to go to to find really common usages.

steveklabnik7y ago

This is a strategy we’re pursuing but haven’t shipped yet https://github.com/rust-lang-nursery/rust-cookbook

oblio7y ago

You misread what I said. Click my link and tell me what you see. Hint: there’s a reason those things are called “suggested extensions”.

j / k navigate · click thread line to collapse