Rust playground with the top 10k crates

announcements
1

Examples:

How does it compare to the official playground?

  • You can use the top 10,000 most downloaded crates in the last 90 days.
  • Support real-time output.
  • Support ASCII color.
  • You can enable features individually.
  • You can specify [profile.dev] for benchmark.
  • You can go back to the last 100 code executions.
  • You can save bins.
  • Longer compilation window (60 seconds).
  • Longer execution window (10 seconds).

https://rustexplorer.com

rustexplorer2
rustexplorer21400Ă—700 51.2 KB

29 Likes
2

I'm just going to talk about me, but:

Given my use cases for the regular playground, I don't see myself doing this. The entire point for me is that I can quickly test something out. In fact I'm mostly using it in lieu of a proper REPL. Anything that lengthens the time span between my question and answering it has negative value in that use case.

The other features do look nice though.

14 Likes
3

Absolutely, if I find a quick test tool like this one that requires me to log in first, I don't even use it. Plus, what is it useful for? I could create any number of user accounts if I wanted to. You cannot prevent users from using multiple instances, but if you want to reduce legit usage of them you can restrict the number of instances by session or by IP for example.

If I'm malicious I will simply create many dummy accounts and that will be it. I understand the reasons behind the login constraint but this is a dealbreaker for many persons.

Otherwise great project! I can't begin to count the number of times I've needed this in the past few months.

8 Likes
4

Sure, you only need to login once (It only takes 2 clicks), and then everything works like you'd expect. Run code in a few seconds.

2 Likes
5

Users that want to create multiple accounts need to create multiple Github accounts too. At least it makes it not worth the effort.

This can't prevent abusers from making direct requests to the api end point as I explained above. There's even an article on dev.to about accessing the official playground api endpoint.

1 Like
6

I didn't see the login was through Github, my bad. This solves a part of the problem - but wouldn't it be possible to ask for the user's ID only? Asking for the email address is not a very good thing for privacy obviously, so this would be a lot better IMO.

That's the only negative point I see here otherwise this tool is really nice :slight_smile:

5 Likes
7

Yes, I would consider it. The initial intention of asking for an email address is in case I need to send important notifications. Maybe in the future it'll have Q/A feature where you can answer directly from the editor. And we need a way to send the notification. Though I don't have a plan to build that feature currently as it's just a side project.

3 Likes
8

Is it possible to use a nightly compiler somehow? (Does not have to be updated super often IMO, mainly just to make sure that unstable #![feature(...)] can be used at all.) If not, is that a feature you intend to add eventually?

1 Like
9

Sure. I do think nightly can cover more use-cases. Maybe next week I'll work on it.

Currently I'm working on enabling streaming + color output. And also fixing some bugs (notice that you have to login every time the session expires?).

Do you have other suggestions?

8 Likes
10

TL;DR for the below: adding dependencies could perhaps be improved, and using explicit versions instead of = "*" has some benefits. And there's certain convenience features the playground has that I might be missing. By the way I haven't really used rustexplorer.com all that much yet.

When working on my local machine, for "playground"-style projects I always use cargo add and cargo feature subcommands to modify dependencies. If there was any way to get the same kind of experience through this website, that would be impressive. IDK, maybe even by running the actual cargo add command, and writing modifications back into the dependencies doc-comment (or creating one if non-existent). (I have no idea how easy/feasable/useful this would actually be though.)

Some "more integrated" kind of indication as to what crates are and aren't supported seems potentially nice, too. Maybe if there was some UI for running cargo add, then typing the command name could offer completions (from the list of available crates) after a few letters are typed?

For the normal playground, you just need to type (part of) use crate_name, and it completes it for you (while indicating the crate version used); the list of supported crates isn't too large, but finding and using them is really easy.

Screenshot_329

Screenshot_330

In a perfect world, you could offer completions is a similar style, and make it automatically (create or) update the dependencies section accordingly, in case the completion is used/accepted by the user. The automatically added dependency would also clearly indicate (and thus document) the latest available version that's used, so that any older shared rustexplorer links would not break due to breaking changes in the dependencies, something that can happen if version = "*" is used instead. (They might still stop running successfully, in case old versions of a crate become unavailable in rustexplorer in the future, but the source code would contain all the version information necessary to get the code running locally.)

Also, if a compilation error includes messages like ^ no external crate `foo` or ^ use of undeclared crate or module `foo` , you might be able to detect this, look up the crate name in your list of supported crates, and suggest the user that they could confirm adding it to [dependencies]. Speaking of error messages, the playground has some conveniently clickable consider importing one of these items instead error messages, where you can click on the suggested use statements to have them added to your code. Admitted that feature is a bit broken/unpolished on the playground, because it will always add it at the beginning of the file, even before potentially existing #![] attributes (resulting in broken code), but I tend to use it regularly nonetheless. Also the playground's support for other modes of execution besides running the code, and automatic detection of whether a main function is present, is quite convenient.

I guess most of these are nontrivial and low priority features, feel free to ignore or postpone most of this.

2 Likes
11

No, please absolutely don't do that, most people would (rightfully) consider it spam if they didn't ask for it explicitly.

12 Likes
12

I've got to say, using it a few more times now, the improvement in speed you get compared to the ordinary playground ist remarkable, especially for subsequent compilations. I'm really looking forward to color support, that's a great idea.

One little thing/idea w.r.t. to the [dependencies] section: If that was supported in outer doc comments, too, not just inner ones; i.e. starting with /*! instead of /**, then you could place it before outer attributes such as #![warn(...)], or once there's a nightly option #![feature(...)], which would be nice IMO, because the [dependencies] section seems like, logically, a separate thing from the source file, so it's nice if it can be the very first thing in the file.

Looking at the sharing features, I haven't figured out yet what “Collections” are or how to use them; and I would probably appreciate a way to share “unlisted” links to code, i.e. make it so you can share something without it (publicly) appearing on your user page.

4 Likes
13

The speed increase when compared to play.rust-lang.org alone made me switch to this playground, thanks a lot for your work.

1 Like
14

I think this feature would be very useful if done right. But the implementation is quite chalenging.

The way the recommendation works on the official editor (Ace only) is by searching ^\s*use\s on the current active line. If you type use inside a block comment \* *\ it'd show the recommendation too.

On Rust Explorer detecting dependency is more involved, as we can't just check ^\s*use\s:

  1. Check whether the current line only contains a valid dependency name (any first word).
  2. Check whether it's inside /*[dependecies] */.

I think the second part is quite complicated, like a code highlighter. Though I'm not familiar with how code highlighters do it. If you know an efficient way to do step 2 please let me know.

/*
This is not a manifest block but any first word character will trigger step 2.
*/

// On outer block, first word will trigger step 2, even when you type fn.
fn main() {
    let message = r#"
First word inside multi-line string triggers step 2.
    "#;

    // Also triggers step 2.
    mess
}

Rust Explorer has mostly only the latest version. Actually you can specify a specific version, but it's not recommended because once the list is updated the compiler may not find a matching version even when the code still works with the new version. The goal of Rust Explorer is to make experimenting with crates easy and quick. And I think most people would prefer to use the latest and greatest dependencies.

I think it's a feature that saved bins shouldn't compile when their dependencies introduce breaking changes on newer versions. This way users won't copy paste stale codes that depend on old dependencies into their project.

The compilation uses --offline flag. So cargo would show an error which crates are unavailable. Rust Explorer has the top 10k crates, which account for 99.9% of total recent crates download. Any crate the you'll likely use in production is available.

Color support is hopefully coming tomorrow.

I agree with you. I think if users try to copy paste the entire code the manifest block should not appear in the documentation. What do you think about using single asterisk /* */? I think it's simpler.

You can move a bin into a collection after you save it. There's a drop down menu beside the bin title.

I do see many people share link to the official playground. But I disagree with the way it stores codes on gist. Spammer loves it. And some users may innocently save the same code with slight changes multiple times. If I'm not mistaken Github has deprecated saving anonymous code.

In what cases do you think people would prefer sharing codes anonymously?

:pray: :pray: :pray: Thank you so much for your feedback. This is the best feedback I got so far.

15

:pray: Thank you.

Big update will come tomorrow (or Friday). Maybe it'll be down for a few hours.

1 Like
16

I thought this is not about anonymity, but about "not cluttering the list with temporary experiments". This might be solved by making two lists - "public codes", visible on user page, and "scratches", available either to the author or by direct link. Can't be sure that I've caught the intent correctly, of course, but this might sound reasonable anyway.

6 Likes
17

I do this quite regularly, on purpose: I’ll share a snippet on a post here, correct it based on feedback, and then share another link. In this case, it’s important that the shared code is immutable— If the code in the original link changes, then the conversation’s context is lost to future readers.

5 Likes
18

For me it's not only about “scratches” (though it would be nice to have a “save” functionality without posting the code publicly), but also for things that only make sense within the context they're posted. Typically for posts on this forum, I use links to the playground. The content is not anonymous and also it's public anyways, but it just feels wrong placed prominently in a list on a user's page like it'd happen on rustexplorer.com currently. Not only that, but I also (feel like I) have to give the thing a reasonable name, etc..

On that note, I just realized that the current interface is really suboptimal as the button labeled “Save” will actually will do an action more akin to “Save and Share Publicly”. Someone might click “Save” without expecting the code to be publicly posted on their user’s page automatically. (The only way I could find out whether or not these are actually public was by opening my user’s page in an incognito tab / or after logging out. So IMO, some better indication on your own page that all the contents are publicly visible would be nice, too, I guess.)

8 Likes
19

On that note, I just noticed that I had actually accidentally edited one of my exiting bins. IMO editing a bin should be more explicit than merely clicking the Run button. E.g. there could be an explicit “Save” button again after you modify the contents, and which gives the option to either modify the original in-place or create a new copy.

6 Likes
20

I have nothing against old shared bins stopping to compile eventually, but IMO the experience is better if it merely says that the specified version is no longer available instead of what you get when using = "*" dependencies: No indication of whether the code used to work at the time of creation, and no indication what that dependency version was at the time, and some potentially confusing error message(s) due to breaking API changes, or even worse breaking changes in behavior not resulting in compilation errors.

If someone wants to run/port old code with/to newer version of dependencies, they should better do so explicitly by bumping the version manually. That said, when doing this, or when initially writing new code, tooling (in the style of cargo add) that automatically chooses the “the latest and greatest” version for you would be very nice, so you don’t have to visit crates.io manually to get the correct version number.

4 Likes