I'm well aware of that. However, using GC fattens considerably Rust type signatures (want a garbage-collected list of garbage-collected Foos? Enjoy writing Gc<List<Gc<Foo>> everywhere). It's just not particularly idiomatic. And Gc types are not Send types, so you can't share them across tasks, which is unfortunate since we were precisely discussing the lack of parallelism in OCaml :)

It's not a dig at Rust, which I think is very well designed, but IMHO, it is in a different niche compared to the other functional languages listed above.

"...writing Gc<List<Gc<Foo>> everywhere..."

Rust, unlike Java, has type definitions[1]; there's no need to use the full expansion everywhere.

(I don't believe it's even necessary in Java, but creating subclasses has its own downsides.)

[1] http://doc.rust-lang.org/0.11.0/rust.html#type-definitions

Yes, you can do that, but it's pretty obvious that if you want garbage collection everywhere, you're not going to use a language with linear types and optional, pretty much discourage GC, and write type synonyms all over the place (or fat signatures), you're going to go for a language where it's natural.

> Rust actually has an optional GC.

Last time I checked (0.10 or so) it did not. Gc pointers were the same as Rc pointers with a proper GC to come soon.

Rust has roughly the same problem as C/C++: without compiler support for garbage collection, you quickly get off into the unappealing-option weeds. In this case, either "conservative" collection, or smart-pointer based collectors, which have performance issues compared to "proper GC's". (As far as GC features go, you can get pretty far with smart pointers: http://maniagnosis.crsr.net/2014/03/automatic-memory-managem... .)