Hi Amasad! I almost replied to my own comment yesterday after I discovered that the rustlings readme[0] now has a link to "Run on repl.it"[1] (as well as Gitpod). Evidently this was added ~11 days ago[2]...although I personally thought it would be a more complicated solution than just configuring the .replit file correctly in the rustlings repo. I had independently come up with the same solution to make the 'Run' button rebuild the .cargo but it felt too 'hacky' for me to accept as a final product and suggest to the rustlings team.

0: https://github.com/rust-lang/rustlings

1: https://repl.it/github/rust-lang/rustlings

2: https://github.com/rust-lang/rustlings/pull/471

A couple of months ago my friends and I tried to get rustlings working in repl.it . I really, really wish I had documented those efforts thoroughly but at the time it was just an exploratory deep-dive to determine if I should follow up with documentation of issues and more detail, and I decided against using my time for that...kind of regret that now.

Three issues I remember facing:

A) inode not updating in the shell even when files changed in the GUI editor. [seems improved now]

B) /home/runner/.cargo/ (and some other supporting directories i think) disappearing after some time / series of actions and-or inaction [today only via inactivity?]

C) At some point we realized the shell wasn't a 'real' shell but I can't remember what led us to this conclusion, just that it got in our way when debugging the above issues.

(A) [Basically fixed already] What I remember is that the repl.it shell environment, while being extremely high fidelity, seemed to have some idiosyncracies in the way the filesystem worked vs a typical bare-metal OS. Two months ago I had trouble where 'rustlings verify' worked okay but 'rustlings watch' wouldn't notice that a file had been edited. Oddly enough, any shell command investigation would also report that the file hadn't been edited/modified recently, but 'cat file.rs' would still output the saved changes.

(B) [Partially fixed, still an "issue" due to long re-builds but not hard blocker] /home/runner/.cargo disappears after any inactivity. This seems more predictable now than I remember it two months ago - two months ago I might only be able to run 'rustlings watch' once and then very shortly after, the shell would no longer be able to find the rustlings binary anymore and I'd have to rebuild from scratch. Generally there were some errors whenever rebuilding, so the solution for me was typically to create a whole new repl.it from scratch and do the initial build. I don't remember what errors caused the "need" for a new repl.it from scratch every time I needed to rebuild it. This still seems like an "issue", sort of, that the rustlings .replit file has a workaround for which works reasonably well and I suspect this behavior is fairly necessary for repl.it the business. But the binaries still disappear after a short inactive period and need to be rebuilt which takes quite some time on the free tier (10+ min?).

(C) [null, and generally not an "issue"] No memory of what behavior caused us to give the shell the moniker "poverty shell" but overall I've generally found the repl.it shells to be extremely high fidelity such that I generally don't realize I'm using a slightly handicapped system. However, this seems to have changed for python shells...now I seemed locked into something like IPython and can't get to a linux shell via exit(), ctrl-D, etc. Maybe this was always the case and I only remember using the linux shell in the C/C++/Rust repl's.

0: https://github.com/rust-lang/rustlings

1: https://repl.it/github/rust-lang/rustlings

2: https://github.com/rust-lang/rustlings/pull/471