this post was submitted on 17 Oct 2025
30 points (100.0% liked)
Rust
7720 readers
46 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
This is awesome. It gets closer to Deno which I think is one of the only things that have actually solved the "ad hoc scripting" challenge, which requires:
At one end we have Deno which nails all of those. At the other, Python which fails all of them pretty miserably (despite this being one the most popular use cases for Python).
Seems like with this Rust will have 1 and 2 solved, and I guess 4 isn't too hard. What about 3 though?
If I eventually decide I want to split my one file script into two files will I be able to?
Edit: I had a play and actually it's good news!
mod fooand it will look forfoo.rs(or I guessfoo/mod.rs) in the same directory!../../commonyou can't just usemodbut you can addcommon = { path = "../../common" }to[dependencies]. That directory has to be a proper crate withCargo.tomlbut I think that's ok and probably desirable.The only downsides I found are:
I honestly would say that's when it goes from a script to a proper project, and you should treat it like that with a Cargo.toml and everything. I think this is a case where it would push you towards better practices and I don't think it should support multiple files like that.
I disagree. That's how Python works but it sucks because it means instead of a C++ (for example) project with some Python utility scripts scattered inside it, you have to turn it into a proper Python project, when it isn't a Python project; you just have some Python scripts in it.
Basically it throws away the ad-hoc scripting use case entirely.