The official Rust Playground now has the top 100 crates available!

[shepmaster]

As of a few minutes ago, https://play.rust-lang.org/ is now powered by the Integer 32 playground implementation! Notably, that means you can use some selected crates! Here’s an example that uses the regex crate.

Specifically, the top 100 downloaded crates of all time are available (edit: as well as their dependencies, when possible). There’s some notion of switching to the top 100 most recently downloaded crates, but that requires changes to crates.io first. We are avoiding hand-selecting any crates to reduce any kinds of favoritism.

This is intended to be a drop-in replacement for the previous playground, so hopefully you won’t notice much other than some small UI differences (and those sweet crates!). Please swing by the GitHub repo and open an issue if there’s a feature you really need or miss! I’ll be removing the “alternate” qualifier from the UI soon, I promise

[nikomatsakis]

Is there a convenient list of which crates are included in that list?

[shepmaster]

There’s a link to the current Cargo.toml from the help page — how does that fit on your scale of convenience?

FYI: Rayon seems to be the number one crate request

[dtolnay]

Here is the list of crates.

---

integer32llc/rust-playground/blob/9ba74ff/compiler/base/Cargo.toml

[Laphicet]

Something doesn’t seem correct about top 100 most downloaded. While I tend to judge by download rate myself there are crates such as pod and futures that are somewhat down the list. These seem to be efficient crates but if that’s the case why aren’t they that popular?

[Fiedzia]

Great. While we are at it - in addition to ASM/IR/MIR, could we see expanded result?

[shepmaster]

could we see expanded result?

What do you mean by “expanded”? There was recently a request to expand macros; is that what you mean? If so, feel free to throw a reaction on the original comment.

[shepmaster]

Something doesn’t seem correct about top 100 most downloaded. While I tend to judge by download rate myself there are crates such as pod and futures that are somewhat down the list. These seem to be efficient crates but if that’s the case why aren’t they that popular?

Could you expand a bit on what you mean by “not correct”? Remember that these are the 100 most downloaded crates of all time. That is, libc has been around since January 15, 2015 while futures has been around since July 31, 2016. That extra time can really add up. This is why we’d like to switch to a “most downloaded in the last X days”.

[Fiedzia]

Yes, this is what I meant.

[mkrasnenkov]

The list seem to include platform-dependent/binding/low level/very specific use-case crates like winapi-rs or vcpkg, I’m not sure if they are intended to be available on playground. I don’t know exactly how download count statistic works, but if it includes downloads made when building more high-level depending crates, the top 100 list might end up containing some items which programmer might not actually want to use directly.

[parched]

Something I would really like to see is IR and ASM for other targets. Is that likely to happen?

[coder543]

@shepmaster It would be nice if a number of these low-level crates (like @mkrasnenkov is talking about) could be excluded from the count. They might still be in the list because of popularity, but when the system sees winapi, it would know to grab another crate, yielding 101 most popular instead of 100 most popular, as an example. There are several of these low-level crates that should be treated similarly… and by-popular-demand crates like Rayon should be manually added to the list.

We are avoiding hand-selecting any crates to reduce any kinds of favoritism.

as long as the community is responsible for the crate selection already (by downloading crates), I don’t see how hand-selecting some crates based on user demand would be any different.

This is all just my opinion, of course.

[brson]

This is awesome, @shepmaster, and is going to make everybody’s Rust experience more delightful. Thanks.

[cuviper]

FYI: Rayon seems to be the number one crate request

It’s close – looks like #118 in all-time downloads right now – but that’s almost ~100k from #100. Without being preferential, would you consider expanding that threshold a bit? Perhaps using recent downloads will be enough to bring it up though.

And just out of curiosity, how many CPUs would be available to playground tasks?
(edit: num_cpus is in there, looks like I got 2)

[budziq]

Let me say how awesome that is!

There’s a link to the current Cargo.toml from the help page — how does that fit on your scale of convenience?

Having this list in a rest/js consumable form would be a great step towards solving one of rust-cookbook long standing problems (how to add run button if there is no guarantee that playground supports given crate)

Issue: Add a Run button to every example

Also it would be awesome if we could somehow coordinate the list contents (add few hand picked crates from libz blitz). do you think it would be possible?

[shepmaster]

The list seem to include platform-dependent/binding/low level/very specific use-case crates like winapi-rs or vcpkg, I’m not sure if they are intended to be available on playground.

Yep; since they have to be compiled as a dependency of other packages, we want to make them available to make as much use as we can of the compilation time we have to spend. Crates like winapi-rs are dependencies of rand regardless of platform, for example.

the top 100 list might end up containing some items which programmer might not actually want to use directly.

I’d suppose that depends on which programmer you are talking about Presumably some programmer is using these crates, otherwise they wouldn’t be in the list!

if a number of these low-level crates (like @mkrasnenkov is talking about) could be excluded from the count

The devil’s in the details here - who gets to determine that a crate is “low level”? Who gets to determine that a crate is “popular” enough to be hand-added? Does it come down to whoever makes the most number of bots? Whoever has a better social media aspect?

[shepmaster]

My first guess would be “no”, but the real answer is “it depends”. Cross-compilation is annoying when having a wide swath of crates (e.g. the native OpenSSL is very annoying to cross-compile, in my experience). There’s other technical difficulties involved, but nothing seems impossible. I’d encourage you to go ahead and open an issue and maybe someone will be interested in an implementation and we can work together to make it happen!

[shepmaster]

Having this list in a rest/js consumable form would be a great step towards solving one of rust-cookbook long standing problems (how to add run button if there is no guarantee that playground supports given crate)

Also it would be awesome if we could somehow coordinate the list contents (add few hand picked crates from libz blitz). do you think it would be possible?

Having a JSON blob that would be easily consumable could also help the Playground — I’d like to be able to easily show which crates are available. Do you know if the list of blitz libraries is available somewhere in a JSON blob?

Using the libz blitz / cookbook is an interesting idea! I haven’t paid too much attention to the details, but there’s likely a fair selection process already established there. Being on the Playground might also be a nice carrot for a library to go through the blitz as well. We should probably check in with that team and see what their thoughts are.

I’ve made an issue for further looking into this.

[briansmith]

Also it would be awesome if we could somehow coordinate the list contents (add few hand picked crates from libz blitz). do you think it would be possible?

Why not just allow every crate?

[jonathandturner]

This is cool Yay for getting an upgrade.

As I play with it, I’m wondering if we could somehow pull in the RLS in the future. One of the nice features about playgrounds like the TypeScript playground (http://www.typescriptlang.org/play/index.html) is that you also get things like live errors and autocomplete.

Not sure how feasible, but one can hope…