[yutijke]

I have seen this perspective thrown around quite a bit. I see where they are coming from, but I can't empathize with it.

Rust's ecosystem does an admirable job in making it less painful to use, but I am still waiting for the day when just chuck any type into Gc<T>. Rc<T> or Arc<T> is not an alternative here. A garbage collector seriously makes business logic way easier to write. And none of rust's other advantages can offset this for Web development.

I know there have been attempts at general purpose garbage collectors for rust but as far as I've seen none of them seem to work seamlessly. Some justifications I've read about it go along the lines of LLVM not having native support for stackmaps?

And given how you have unmanaged native pointers lying around everywhere, I don't know if you could even have a general purpose GC without putting heavy restrictions on code that uses it effectively creating a split dialect.

[koito17]

I'm not sure why this is being downvoted. Are people disagreeing that manual memory management adds overhead compared to GC'd languages for prototyping?

I'm expecting my own comment to be downvoted as well, so I'll give a huge disclaimer that I lack experience with Rust, but I always find myself playing type tetris and having to think hard about memory management whereas Clojure, JavaScript, and Python all have interactive solutions that let one quickly hack together some web server and endpoints.

[yutijke]

"Type Tetris" is the perfect description of what I've felt with rust at times for stuff where I don't care too much about performance but don't want to wrap everything with Arc<Mutex<T>> or .clone() everything.

I don't say this from a perspective of distaste. I really like rust's ecosystem and tooling, but would really love to use `RustScript` one day which is basically Rust with a hint of Go. Green threads and all references can be treated as if they are effectively pointing into the heap.