[adwn]

> But the problem with that is that the market that really really can't use GC is vanishingly tiny.

If you write a library in C#, you can use it from .NET languages. If you write a library in Java, you can use it from JVM-based languages. If you write a library in Python, you can use it from Python. If you write a library in Rust, you can use it from any language that can bind to C, which is virtually every language that matters.

That is not a "vanishingly tiny" market. It might not be your market, but that's okay: Rust doesn't have to be for everyone in order to be important.

> And then Rust implements reference-counted pointers in the library, which is the slowest possible way of collecting some, but not all, garbage.

That might be the case if you were to replace the JVM's GC with reference-counting, but Rust enables a data layout strategy in which a lot fewer allocations of larger individual objects take place (because not every object requires its own heap allocation). This way, RC in Rust is probably not slower (maybe even faster) than the GC in the JVM, while having a lower memory overhead at the same time.

[tom_mellior]

> If you write a library in Python, you can use it from Python.

Or from C. Or from any language that can bind to C. Like Rust. I'm fairly sure the other languages you listed also allow calling from C and hence from Rust, as well as among each other.

> not every object requires its own heap allocation

Sure. That doesn't change if you add a GC to Rust: Objects won't magically become non-stack-allocable if they were stack-allocable before.

[adwn]

> Or from C. Or from any language that can bind to C. Like Rust. I'm fairly sure the other languages you listed also allow calling from C and hence from Rust, as well as among each other.

But then you have to include a foreign language runtime! Together with all the headaches and interoperability complications that entails. How many .NET applications do you know which include a JVM runtime, or how man Java libraries include on the Python runtime? Now compare that to the number of applications or libraries (in any language) that directly or indirectly depend on a library written in C or C++. Rust will have the same advantage.

> That doesn't change if you add a GC to Rust: Objects won't magically become non-stack-allocable if they were stack-allocable before.

My point is that a GC probably won't have a positive effect on most programs written in idiomatic Rust, therefore there's no need for it (contrary to what you claim).

[tom_mellior]

> Now compare that to the number of applications or libraries (in any language) that directly or indirectly depend on a library written in C or C++.

Every significant C++ library I've ever used had its own stupid intransparent memory use conventions and invariants and segfaulted on you if you unknowingly violated them. The only difference is that you call some libraries "libraries" and other libraries "runtimes". I don't think that divide is all that sharp.

> a GC probably won't have a positive effect on most programs written in idiomatic Rust, therefore there's no need

It would allow new idioms that many people would find useful because not all code is code where performance is more inportant than clarity.

> (contrary to what you claim)

I didn't claim that Rust needs a GC to be Rust, I claimed that Rust needs a GC to be a more popular, more-widely-regarded-as-useful language than today's Rust.