State of rust repls?

  1. I am aware of

  2. I am also aware of a number of not-updated-in-months “rust repl” type projects.

  3. What is the current state of having a “Rust Repl”? I’m currently using nightly, am willing to try experimental packages, and just want to see how close to a Repl we have for Rust.


#2 is promising. I used it last night to kick off a quick intro to Rust hour meetup.

Under the hood, it uses rustc so there’s a bit of a lag.

I think a fully featured REPL would be a marvelous thing, but totally non-trivial. I blew several years doing a C++ interactive interpreter (UnderC) and it nearly drove me mad.


@stevedonovan : In your opinion, would an “interpreted” Rust be any easier? The main thing I want is something like this:

  1. I have a bunch of existing Structs / Traits / Functions / Impls.

  2. I want to evaluate some expression and see the value. Right now, this involves creating a

pub fn test_00() {

unit test just to eval the expression.

  1. If we had a “100x slowdown interpreter”, where the pre-existing Structs/Impls/Traits/Funcs ran at full speed, and the interpreted code I wrote ran with a 100x slowdown, I think I’d still be okay with that.

  2. Based on your experience, what are the hidden brick walls preventing this from happening?


I agree that this is how I would expect a proper REPL to work; to ingest precompiled crates and evaluate expressions and simple code in ‘interpreted’ mode. One problem is that dynamic linking hasn’t really been a first-class citizen, which requires some fiddly work outside Cargo. (Otherwise would have to embed interpreter into a big binary). The main problem is that Rust is a subtle language which only has one fully compliant implementation: rustc. Something like evcxr uses rustc to compile expressions as shared objects - there are some distinct limitations.


I simply use the playground as a REPL when I want to quickly prototype an idea.

A CLI-based REPL would be pretty nice to have, but Rust is a monster of a language, specifically in terms of size and number of features. This has an consequence: Unless it was an official part of the Rust distribution, a REPL would probably always lag behind the compiler and the language proper i.e. now that 1.31 is out, the REPL might still be stuck feature-wise on rust 1.28 or even earlier.

There’s also the premise that Rust is built AOT compilation. How (well) does that mesh with the interactive nature of REPLs? In particular, how would macro’s be resolved?


My current solution is to use the runner crate:

dev$ runner -e ‘Path::new(“hello”).with_extension(“txt”)’

Edit: it understands ‘snippets’, i.e. without fn main boiler plate. Original inspiration was documentation snippets.


That’s a good start, but really it’s the least of the issues such a REPL faces.
The boilerplate is exactly that and as such is easily inserted automatically by the REPL software.