I'm currently going through the rust book. When I want to test something, I need to
- go to test project
- edit the code
- run
cargo run
It would be faster to just spawn a rust terminal and write the code there. I can't find any info on this online.
5 Likes
I have not tried it, but did you read Is there a Rust interpreter? or directly the github repo evcxr.
Actually, I did try it now, and works pretty well, just like your Python or Node.js REPL.
Nice question!
7 Likes
For small tests the Rust Playground works quite well: https://play.rust-lang.org/
3 Likes
Yep that's exactly what I'm looking for. Didn't know it's called interpreter. Thanks!!
Didn't know it's called interpreter.
The proper name for the thing you are asking for is a REPL. They are often confused with interpreters because it is far easier to build a REPL when you have an interpreter than when you don't, but a REPL is a kind of user interface, and an interpreter is a kind of language implementation.
10 Likes
I played around with evcxr a bit some years ago. I thought “that's neat", then never used it again.
I don't know why, but I really haven't found a need for it when coding Rust. Yet in python having a REPL is essential. I don't miss a REPL when coding C++ either.
I assume it is something with static vs dynamic typing that makes this difference, but I am curious as to others experience and thoughts on this.
1 Like
Interesting, all my colleagues are using Python, I don't recall them ever using REPL. I can see the usage though, I use node.js or deno as a REPL when I want do some one off calculation, like a glorified calculator.
Yeah, I think historically building anything in a compiled language like C, C++ was a complicated slow process not really "type and go" like you would like.
Now a days machines are fast and a language like jai can compile little REPL sized experiments in almost no time.
What about using cargo watch?
$ cargo install cargo-watch
$ cargo watch -x run
Then edit code and it runs immediately.
Interesting. For me, having a REPL, or even more so "dump me into a REPL at this point in the code" is essential in Python. Because you can never quite trust the type annotations. And you often have ad-hoc types, e.g. a tuples of 3 strings and 2 integers. What do they even mean? Who even calls this code? What code does it call? Who knows, it is all abstracted away. Best to check interactively.
Same goes for figuring out what code to insert at that point. Let's play around with various functools, itertools and list comprehensions at that point and see what works.
In Rust and C++ you don't run into those nebolous types very often. And the compiler, IDE and tooling are far more reliable. You can trust the language server (assuming you are not in knee deep in a Rust/C macro or C++ template). And even when the IDE goes on the fritz, the compiler will still ensure you are doing the right thing, especially in Rust.
This goes hand in hand with fearless refactoring. When coding new Rust I often spend long stretches of time without building and running the program. Check is enough.
(Of course there are later other phases with quick iteration cycles: when ironing out the few remaining logic bugs, when optimising with a profiler / benchmarks, when finishing up tests. But this is not the bulk of the time.)
2 Likes
Me too - though I tend to reach for the python or lua repl - but there are lots of others.
nushell is also an option - it can also do arithmitic expressions, although annoyingly it requires you to put spaces between the terms "1 + 1" not "1+1".
jupyter notebooks are also 'repl like' - and you can do that style with rust and evcxr, but I don't think it is necessary or a good approach. You have to view the code through a web browser and fall back to 'notepad' editing.
Etc, etc.
I can totally see how that goes.
For tackling those particular problems a REPL in Rust is not really required. Because rust-analyser is already telling me where I'm going wrong as I type. Giving me type hints and so on.
In fact, thinking about, in a days coding I rarely compile or run what I'm creating. I'm mostly having a conversation with the rust analyser or sometimes the results of cargo check. Then I try to create tests for functions and methods as I go, so cargo test is doing what Python users seem to be doing with the REPL. With the significant bonus that tests are persistent, ready to be repeated at any time, rather than having to manually REPL it again.
Only when things are in some state of "done" do I rebuild the whole thing and see if it does what I actually wanted. Which it usually does, thanks to all the above.
1 Like
A bit of a tangent, but the discussion of interpreters and REPL for Rust reminds me of the Rhai scripting language.
For code even modestly more complex than the examples from the book, I find the value of programming on the fly in a REPL is low compared to working with cargo run. Coming from a background of "interpreted languages" myself (Python and R), the compilation step initially seemed like a big speed bump in my workflow, but I have come to see it as a good thing.
This comment from @Vorpal resonated with me:
A strong type system, combined with ownership rules allow users of the Rust language the ability to catch a wider class of programming errors during the compilation phase, rather than at runtime, in the REPL. This means you can detect a wider range of errors before your program ever runs, and has inspired the widely-held mindset that if it compiles, it runs.
As the complexity of the programs that I write grows, I find myself increasingly reliant on program invariants encoded into the type system to enable the compiler to check my work for me.
Also at a tangent... I have recently learned that Haskell can be run from a REPL and also does something very sneaky with its C FFI. If I understood correctly it will compile C functions on the fly into a dynamic library then load and run that from the REPL.
Sounds like one could arrange for Haskell to do similar with Rust. Or have a REPL in Rust that dynamically compiles Rust to dynamic libs and runs those. I have no idea. Certainly not a task for me.
1 Like
try this one: https://rust-script.org/
There is also a similar unstable feature in cargo:
(doesn't handle the REPL use case though)
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.