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
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?
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.
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.
@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.
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)
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?
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.
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!
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?
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!
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.
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.
reaction on the original comment.
Presumably some programmer is using these crates, otherwise they wouldn't be in the list!
Yay for getting an upgrade.