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:
Easy to install language.
Easy to use third party dependencies (from a single file script).
Easy to import from other files without setting up a whole project.
IDE support.
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!
If you want to split up a script you can just do mod foo and it will look for foo.rs (or I guess foo/mod.rs) in the same directory!
For common code, which you might want to import from e.g. ../../common you can’t just use mod but you can add common = { path = "../../common" } to [dependencies]. That directory has to be a proper crate with Cargo.toml but I think that’s ok and probably desirable.
The only downsides I found are:
No IDE support yet.
It prints compilation messages to stdout, which kind of sucks.
Even after it has been built, it still does incremental compilation every time you run it, leading to more compilation message noise, and ~100ms startup time.
If I eventually decide I want to split my one file script into two files will I be able to?
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.
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.