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

announcements
21

That's always a possibility, but I've yet to come up with or hear a workable solution that doesn't cost lots of money or expose a service for abuse.

Right now, all the crates are precompiled so that when you click the run button, only your entered code needs to be compiled. At one point in time, doing that was faster than the original Playground's server-side cache! Speed feels like a very important aspect to the Playground, especially as it is likely to be used as an introduction to Rust to people who just want to play around.

Additionally, the user's code is run disconnected from the outside world. By definition, having arbitrary crates means we have to be able to download the crate in question. Build scripts in the crate can then do lots of things.

The Playground right now is entirely stateless - a Docker container is created and destroyed for every compilation. This leads to very easy management.

Please don't take me wrong — I'm open to suggestions on implementations, and in doing so I'll probably discover "hidden" requirements like "gotta go fast". All the work on the Playground is volunteer, so any complex, finicky solution starts off at negative points.

22

Rust Playground (click ? to access it) still says it is "The Alternative Rust Playground" :smirk:

3 Likes
23

The Playground (like the original) uses the Ace editor. There's at least some notion of extensibility to provide things like autocomplete, but I've never really looked into it.

A concern I'd have would be the server-side requirements behind it. Having a fully stateless server provide things like live errors or autocomplete seems... expensive. Moving from stateless to stateful seems like it would entail a lot of operational overhead (also expensive).

I wouldn't be surprised if there's a middle ground of using some of the same guts as RLS to provide very rich information on demand though.

24

Haha, yeah... I didn't want to lay claim to the title before it was true, and then the switch happened at 10AM local time... while I'm working at a client. I've been trying to keep up with forum posts and bug reports, and plan on addressing some of the easy / obvious issues at our weekly Rust meetup tonight :blush:

2 Likes
25

We do not have an easily consumable crate list (the most up to date list can be found on
libz-blitz crate list etherpad which covers both ready and scheduled crates) but this could be fixed easily enough.

We should probably check in with that team and see what their thoughts are.

Well @brson is the highest profile member but dtolnay, @KodrAus and myself would be available for discussion. ATM I'm mostly involved with the rust-cookbook.

2 Likes
26

I've used clap pretty extensively with the Integer32 playground, but it's not listed here :cry: I'm on mobile right now, but was it removed from the I32 playground too?

Edit: Ah ok, this was a hand picked list not a most downloaded list like I'd thought. My mistake :stuck_out_tongue_winking_eye: . Still curious about the I32 playground though, I'll have to check it out agin when I get home.

27

Anyone noticed that the code on a front page doesn't run anymore?

3 Likes
28

Isn't the list sorted in alphabetical order?

1 Like
29

I want support for Intel assembly syntax

1 Like
30

It is actually the same list (both playgrounds are using the same Docker containers, even). I had to temporarily remove clap due to some incompatibilities while resolving it's dependencies. I expect that refreshing the list in a little while will resolve it; if not I'll look around for where to log the appropriate bug.

1 Like
31

Uggggh. Way back in the day, this (and the documentation) went to the playground directly, not staying on the same page. This is my #1 thing to fix tonight!

1 Like
32

Indeed. There's a part of me, too, that hopes we could get rustc/rls running in wasm, which should free us up a bit to do the compilation inside the user's browser.

3 Likes
33

I don't think we've got a consumable list of libz blitz crates, but there is this etherpad that lists a bunch of potential crates to review.

We're an automation community though, so I think offering some kind of consumable list of fundamental crates is a good idea. Even just starting with a json blob in a GitHub repo.

35

We already have it.

BTW I too don't like current horizontal layout, as old vertical was much more suited for wide format displays.

36

It's being worked on!

1 Like
37

One feature I'd like in the Playground is a button to switch between a 32 system to a 64 bit system. This is handy because sometimes some code that works on 64 bits with usize gives a overflow error on a 32 bit system (or gives wrong results in release mode).

1 Like
38

Top 100 most popular is a good approximation, but I think we might need to change the way crates are selected. Instead of 100 most popular, we might need 100 most requested, with some caveats. E.g. I'm not sure you could really use Diesel or Rustqlite or rust-postgres, without access to a Database.

For example testing out proc macro in playground seems impossible, which I really would love to toy around.

2 Likes
39

We have been discussing with @shepmaster about PR based crate whitelist submission scheme for LibzBlitz / rust-cookbook. I hope to take up the discussion one I'm back from vacations.

40

Shall optional dependencies of included crates be also included?

For example, there is now no http crate in playground although there is hyper which optionally depends on http.

41

I believe the reasoning for exposing all the dependencies of the top 100 crates was that the playground server needs to compile them anyway already, so they might as well be exposed. That does not apply to optional dependencies that are not already being compiled by the playground.

2 Likes