Call for testing for cargo-script
(github.com)
from SorteKanin@feddit.dk to rust@programming.dev on 17 Oct 22:48
https://feddit.dk/post/16585000
from SorteKanin@feddit.dk to rust@programming.dev on 17 Oct 22:48
https://feddit.dk/post/16585000
threaded - newest
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?
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.
I really wanted this feature, but when I actually used it, I realized that it’s not quite as useful as I would have hoped, at least for the use case of just a “small” rust script.
A workflow I often have is to start hacking away at a problem with bash or some other scripting language, but then my command starts getting too long and unwieldy so I copy my command into a file to keep going. But with rust, you don’t really do that, so I never progress to copying my command into a file.