cargo-script-mvs VS wg-allocators

The eRFC was intentionally light on details so the Pre-RFC / IRLO thread and the demo best reflect what we hope to accomplish which are pretty detailed as-is.

> A) is easy to write one off scripts that do a job fast, with minimal thinking and effort. I am thinking of Python and Ruby. For me I can write code with high velocity in these languages.

Once I wrap up some other projects, I plan to explore this space a little bit within Rust.

imo the biggest bang for the buck is just having good `#!` support. Probably mid-year I expect to have a Pre-RFC up for single-file cargo packages. See https://github.com/epage/cargo-script-mvs/discussions/15.

A bigger effort is a batteries included, non-zero cost stdlib. I've started writing up my thoughts at https://github.com/ergo-rs/ergo.

For more background on why I think these are important, see https://epage.github.io/blog/2021/09/learning-rust/.

Would love feedback on these ideas and other ways to make Rust easy to use without sacrificing what makes Rust it is.

This is something I'm interested. Every time I write a bash or Python script, I think "why didn't I do this in Rust?". The first barrier is in the same line as your thoughts which is why I've been investigating the various cargo-script spin-offs and working towards an MVP for a Pre-RFC.

Something I've been thinking a lot about for Rust is what can and should a REPL experience be for a compiled language (ie what are reasonable compromises).

There seem to be two repls that haven't gotten much traction:

- https://github.com/google/evcxr/blob/main/evcxr_repl/README....

- https://github.com/sigmaSd/IRust

There have been little and big nits that have held me back from wanting to push these further, including

- Bad defaults (having to opt-in to panic handling)

- Command syntax feeling out of place and likely not beginner friendly

- Limits on variable preservation

- Lack of introspection (at least irust as `:type`)

So far I've been punting on wanting to improve this area by instead focusing on polishing up a rust script solution in the hopes of getting it merged: https://github.com/epage/cargo-script-mvs

rust-script is the most up-to-date version I could find. See https://github.com/epage/cargo-script-mvs/discussions/15

cargo-script has been forked or reimplemented several times.

cargo-script: I've done some initial analysis and recorded my thoughts on what cargo-script in Rust should look like. If people are interested in this or other individual / company on-boarding improvements, I'd love to talk!

Fully agree with this though I also feel there is room for experimentation and improvement in this area. I've previously blogged on this and have started researching cargo-script. Hopefully later I'll get to my standard-adjacent library.

Tracking issue for Storages, and a TLDR on what it is

I must have gotten confused, since from your brief discussion with CAD97 it seemed like there was a way for the concepts to live separately and that Storage could complicate things in comparison. But if implementing Allocator in terms of Storage is basically equivalent and Storage is flexible enough that I could write one to pass memory out to unsafe code, that works just as well.

https://rust-lang.github.io/rfcs/1974-global-allocators.html was the original RFC.

My vague understanding is that there's a working group https://github.com/rust-lang/wg-allocators

The further I get from working on Rust day to day, the less I know about these things, so that's all I've got for you.

If you self-reference using pointers and guarantee the struct will never move, you don't even need unsafe. If you self-reference using offsets from the struct's base pointer, you need a splash of unsafe but your struct can be freely moved without invalidating its self-referential "pointers".

Per-struct allocators are a work in progress (see https://github.com/rust-lang/wg-allocators/issues/48).

Not sure what "non thread local addresses" means, but in my experience Rust is pretty good at sending data between threads (without moving it).

Besides that allocation is not really a problem for no_std. It's resolved by using alloc crate directly, so anything usable with custom allocators is supported. Example in dasp sources - https://github.com/RustAudio/dasp/blob/master/dasp_slice/src/boxed.rs#L14-L19 . Also worth looking at this issue to check what is usable already - https://github.com/rust-lang/wg-allocators/issues/7

But that's on track for rust as well: https://github.com/rust-lang/wg-allocators/issues/7

Here: https://github.com/rust-lang/rfcs/pull/1398. there is also a working group for this: https://github.com/rust-lang/wg-allocators.

It's unstable. wg-allocators contains discussions about design and a tracking issue for collections that need an allocator https://github.com/rust-lang/wg-allocators/issues/7