Why shouldn't a high-performance concurrent GC implementation enter the standard library? I think it might be quite useful if it did, for the rare use case where possibly-cyclical graph structures make sense and Arc<> is not quite enough.

This feels unlikely. Rust is trying very, very hard to not have a runtime [1], by opposition to Go (which ships the runtime in every executable) or Java, .Net, JS, Python... (which require the runtime to be installed separately). That's why you need tokio (or some other executor) to execute async code, for instance.

The benefit is that it makes Rust much easier to maintain and port to new architectures, and much more polyvalent, e.g. you can use Rust on true embedded, by opposition to most other modern languages, and presumably more future-proof. The drawback is that you, as a developer, need to pick a runtime.

[1] In truth, there's still a runtime, but it's really tiny.

I think it’s less about the runtime and more about nailing down and stabilizing the implementation details. GCs have a lot of subtle trade offs just like async runtimes (i.e. like the decision to require Send + Sync versus single threaded Futures) where there’s no obvious sane default. There’s too much variation in what the community needs from a GC compared to something like a HashMap where a general implementation works fine with options to change the hasher or allocator covering >90% of use cases.

I think most async runtimes give you the option of launching a single-threaded executor when you explicitly request it.

AIUI the most esoteric tradeoffs wrt. GC involve how to have data representations that can be efficiently traced, and whether you should allow e.g. moving data in memory as part of the collection phase. But I think you're overestimating somewhat the variation within the Rust-focused community - given what most Rust code looks like, they're going to be mostly interested in something straightforward yet efficient, that can interoperate with existing Rust code w/ relative ease while addressing the common issue of cyclical data references.

You make a good point, but what's discussed in the OP seems to be less complex than a full async runtime, e.g. it does not really depend on low-level OS features. So it seems to be the kind of thing that might become part of the standard library at some point, much like the Rust HashMap. You would still be able to avoid it altogether by just not using Gc<> objects (you "don't pay for what you don't use") so it wouldn't be a true runtime.

As already stated, one of Rust’s explicit goals is not to have a runtime of any kind. If your program happens to require a garbage collector, and you want to write it in Rust, then you can simply depend on a garbage collector provided by a crate. No need to have it built in when 90% of programs don’t need it. And since you can just include one when you do need it, there can easily be multiple options to choose from. As engineering is all about managing tradeoffs, you want to be able to choose the crate that best matches your particular needs. A single option buried in the standard library and forced upon you may not be the best choice.

That said, most programs should not be written in Rust. They should be written in a language that, like Rust, is memory safe, but it is best if they are written in a language which makes the developers more productive than Rust does. Languages with garbage collectors built in are at the top of that list. Common Lisp, Javascript, Python, Raku, etc; there are plenty of choices. These languages are ideal for exploration and productivity. Even Java or C#, if you can stomach it. Save Rust for later when you have to squeeze every drop of performance out of your program, you’ve already written it once so that you already know exactly what you need, and you can justify the expense of the rewrite using operational savings. Optimal performance will probably happen once you can drop the garbage collection entirely, and Rust truly shines when used that way.

> it is best if they are written in a language which makes the developers more productive than Rust does.

AIUI, recent assessments (including by Google) have found that Rust developers' productivity is competitive with GC languages such as Go.

There's also plenty of reasons to think that a program that's first written in Rust will have fewer defects in the long run than the other languages you mentioned. Of course alternative languages may still have a role to play for quick-and-dirty, purely exploratory coding, but that's about it.

True, but it is my understanding that in those cases they were reimplementing existing services, where the precise requirements are already known. Exploration isn’t for quick-and-dirty programs, but for finding the right solution in a wide space of possibilities where you don’t even know what all the requirements are yet.

For example, consider programming a game. If your only concern is putting triangles on the screen, then there are some well-known solutions that you can adopt that will work great and you can do that in any language you want. But gameplay mechanics are a different beast entirely; inventing (or discovering) something new and fun is exploratory. You’ll benefit most from a dynamic language where you can change your code rapidly, and features like strict typing and lifetimes are not so helpful. For this a language like Common Lisp, with garbage collection, a REPL, gradual typing, just-in-time compilation, and support for multiple programming paradigms is ideal. Or Javascript, or whatever.

> The benefit is that it makes Rust much easier to maintain and port to new architectures, and much more polyvalent, e.g. you can use Rust on true embedded

"supposedly" Rust's architecture support for all but the most popular archs is horrendous.

> "supposedly" Rust's architecture support for all but the most popular archs is horrendous.

Unpopular architectures are a bit of a pain. But what if you compiled from Rust to WASM and then transpiled the WASM object code to C? Is this a viable approach?

Well, to be frank, the unpopular archs aren't really well supported by other languages.

You may be thinking "What about C?" and the answer is that for those unpopular archs you are almost certainly looking at a hand patched version of GCC (3.2... probably) created by the vendor to support C.

You generally won't see good support for unpopular archs mainlined in compilers.

The structure of Rust makes it possible to port it to those architectures, and if Rust continues its present momentum, someday in the future you’ll be just as likely to see some random embedded system support Rust as it is to support C now. We just haven’t had the time for it to catch on enough to get there, but there’s nothing fundamental about the language to prevent it.

> or Java, .Net, JS, Python... (which require the runtime to be installed separately).

Modern .NET has both modes that can 'include' the specific runtime bits built against, as well as AOT compilation modes that don't involve a jitter and can be smaller (heck with enough effort you can get Snake in about 8kb[0]).

> e.g. you can use Rust on true embedded, by opposition to most other modern languages, and presumably more future-proof. The drawback is that you, as a developer, need to pick a runtime.

Also -technically- possible on .NET but may require more finagaling, There's been at least one POC where a C# app can run in EFI [1]

The drawback in .NET's case vs picking a runtime, is you might have to do finagaling/tweaking/shimming on your own since there are few docs/templates.

[0] - https://github.com/MichalStrehovsky/SeeSharpSnake

[1] - https://github.com/MichalStrehovsky/zerosharp/tree/master/ef...

To add on to the siblings one of the major motivating use cases for rust is to interact with another GC, originally the JS runtime GC for the servo browser. An on-by-default one would interfere with that usecase heavily. What I could see and there have been some half-hearted efforts in this direction is to standardize on a `Trace` trait so that users who want to bring their own GC can do so safely and can allocate std lib objects into the GC heap without concern.

I guess where I disagree is wrt. viewing something like the OP's implementation as something that's "on by default". To me it seems to be pretty much the opposite of that. You're right though that a standard Trace trait might be interesting.

The Rust philosophy is to add as little as possible to the standard library, for many reasons, but particularly because otherwise you have to update your compiler to get library updates (which also means long release cycles).

This is why there are various "de facto standard" crates for basic things like regexes or error handling that would be built-in in other languages.