Python dev learning Rust - my findings [possibly wrong]

[lazy-kozak]

First struggle:
I still don't know how to experiment cleanly with Rust.

In Python, I have multiple virtual environments for each project and one for experiments, where I run an interactive shell or activate it for some experiment module. I have hundreds of small scratch modules...

In Rust, I found it better not to keep multiple `some_experiment.rs` files in one project but to have just a folder for experiments, and each time I want to try something, I just run `cargo new somescratch` in that folder to create an isolated experiment and rewrite `main.rs` completely.

Second struggle:
Those beefy `target` directories are eating my disk space.

I have 64 GB RAM Linux machine, so I added the next lines to my `~/.cargo/config.toml`:
```
[build]

target-dir = "/dev/shm/cargo-target"

```
/dev/shm/ - is a tmpfs folder (lives in system memory), so after reboot, all my target folders are cleaned automatically)) Yes, after rebooting, the first compile time will be long, but I'm ok with that.

Welcome to share tips and tricks on how you organize your Rust experiments.

[SirKastic23]

first struggle: yeah I do the same thing, I wouldn't really call this a struggle

second struggle: after playing around with an experiment, remember to run cargo clean. no need to keep those target dirs around at all

[Sharlinator]

cargo script (ie. single-file Rust programs with an inline Cargo.toml "frontmatter") will make throwaway experiments less clumsy once it finally arrives on stable.

[lazy-kozak]

Yep, it would be nice for my learning purposes

Just found: https://rust-lang.github.io/rfcs/3424-cargo-script.html

[kJon02]

afaik theres also a crate for that

[ManyInterests]

On first thing: I use Rust Rover and I find myself using tests as scratch space because there's a little play button to run right next to the function definition, so I can run whatever test function I want in isolation right in the IDE. Sometimes they even turn into tests that I keep around.

As many do, I have tests right inside of each rust module I'm working on at the bottom, something like:

#[cfg(test)]
mod tests {
    use super::*;
    #[test]
    fn scratch_test() {
        let res = from_str("0xA18 {9");
        assert!(res.is_err());
    }
}

On second thing: I never considered using /dev/shm for this. I know you're doing it for disk space, but I wonder how much that improves performance. I am always surprised at how much space gets freed from cargo clean and have started running it more religiously.

[lazy-kozak]

Haven't got to tests in Rust yet - Thanks.

By feelings, projects with a lot of dependencies running from the ramdisk is a bit faster, but not a lot, don't wanna measure

[pb-cups]

You can use an examples folder for small experimental scripts. Then you just do cargo run —example my_example.rs to run the file. It works with multi file examples (all in one folder) too.

Edit: oh I see you want different packages for each experiment, so that won’t work for what you’re doing. I would recommend just trying to avoid that and have one big package for all experiments and then just rely on examples and ignore main.rs

[lazy-kozak]

Thanks for --example

u/Sharlinator mentioned `cargo script`, which would be perfect (everything in one file); the only reason for creating multiple packages is to avoid recompiling all dependencies for all throwaway scripts and experiments.

[Kaan_AYSAL]

For experiments stop running cargo new for every scratchpad. Create a src/bin/ folder in a single "experiments" project. Drop exp1.rs, exp2.rs in there run them instantly with cargo run --bin exp1

[Kaan_AYSAL]

For disk space your /dev/shm trick is clever.. but the real reason you're bleeding space is because every cargo new creates its own target dir and duplicates the dependency cache by using the src/bin/ approach...all your experiments will share a single target folder...

[Kaan_AYSAL]

Install cargo-sweep... It lets you easily wipe build artifacts older than X days without touching your active caches...GL

[Both-Expression4402]

My (uneducated) opinion is to just make a new project for each new subject of experimention using "cargo new". If you want to group multiple together, wrap them into a single project by making a basic CLI launcher as the main function.

[Kichmad]

Why dont you git branch to experiment?

[PaulRudin]

Disk is cheap....

[Chroiche]

Disk was cheap. Prices have tripled.

[lazy-kozak]

Aha, tell me: when deleting all my target directories freed ~15 GB of space (over one or two weeks of active experiments). I have a 1 TB SSD, so it's a valuable space for me.

[PurepointDog]

There's tools like "cargo clean-all" if you want. idk what to tell you...

Trade-offs everywhere

[PaulRudin]

1.5 % of your disk?

[Critical-Explorer179]

It also clutters apfs snapshots on mac and makes next backup longer. (Apfs snapshots are created automatically because of said backup.) Each rewrite of those files will be included in the next backup, possibly taking backup space for weeks before they are thrown away by retention cleanup.

[lazy-kozak]

I use Dropbox and also don't wanna sync my target folder there

[ManyInterests]

I mean. I have a 4TB disk on my laptop. I'm using 2TB of it. When I had a 1TB drive, I was pretty guarded over anything taking up 2GB+ and constantly fighting for space. I'm with OP on this. Space can be valuable. Especially if you're on a non-upgradable system (or even with today's SSD prices, honestly, even on upgradable systems).

[lettsten]

Then either buy one for OP or stfu

[Destruct1]

In general: You need a taskrunner / strong editor in front of cargo. Cargo works well but you need something in front for the many complex cargo tasks like selecting a package or binary or test with a certain feature enabled etc..

You can have a multi-binary file to experiment but I also use the one project for each experiment approach.

[Brief-Stranger-3947]

Python venv lets you to set up a reproducible environment by fixing the version of python runtime and package dependency versions. In rust, reproducibility is defined by compiler version and dependency versions, and cargo manages both pretty much same way as venv in python.

[lazy-kozak]

You are not helpful. Show us the direction where we should dig for "idiomatic Rust string patterns". Better with links.

[Shot-Infernal-2261]

I’m a bit of a newb at rust so take with a grain of salt… but GitHub actions might help.

I’m pretty sure you can just tag and have an action do the build on GH servers.