[tom_mellior]

> Rust's genius is going after the market that can't use GC

But the problem with that is that the market that really really can't use GC is vanishingly tiny. Rust throws the baby out with the bathwater and tries to pressure others into thinking that they are in this market. Most developers on most projects aren't.

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

Honestly, if Rust is to become popular, it needs (a) to get rid of this elitist "we are awesome systems programmers" mindset, and (b) a good, optional way to use a GC where it makes sense, with good support for migrating away from it (i.e., by giving you a list of "I cannot determine the lifetime of this object, so it will be allocated on the GC heap" diagnostics on request).

Good cases can be made for having a no-GC mode, but having it exclusively is just premature optimization.

[yaantc]

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

It's huge, but specialized so may not be on your radar: small embedded devices. Think RAM size from 10s to 100s kB, and Flash from 100s kB to few MBs as rough ranges.

The interest for IoT, and the need for battery operated devices with lifetime of 10+ years, make such platforms very important. And cost and process constraints (like embedded Flash) lead them to be implemented in conservative nodes: 55 to 40 nm typical, will go to 28nm in time but unlikely to go lower. So the amount of processing won't change much in this space I believe. An any gain would not be used to get a bigger CPU/RAM, but to reduce cost and power (less power is smaller batteries => cost too). So this space will stay on the very small side for the foreseeable future.

These are devices that run on very small micro-controller cores and are too small even for a striped down embedded Linux distro. It's either RTOS, or even simple run-to-completion preemptive schedulers, or even bare metal. No room for GC here, and Rust with its focus on performance, leanness and safety is very well suited as a language.

As a platform, the fact that there's only one LLVM based compiler for Rust is a limitation in this space. In the deep embedded space there are a lot of architectures for which there's no LLVM support (Cortus, Andes, BA Semi, LM32, Nios, ...). But I hope this as temporary. GCC is the most common toolchain there, and hopefully at one point GCC will gain a Rust front end. Or maybe LLVM will become more popular in this area? We'll see.

[tom_mellior]

> No room for GC here

True, if you're talking about tiny embedded systems where you would not use GC (nor any dynamic allocation), you shouldn't have much difficulty using Rust. Nor many of its benefits.

[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.

[jeffdavis]

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

Even if that's true (which I don't believe), tiny markets have a way of expanding when new offerings are available.

New people are getting involved in OS development in rust, for instance. We might see some really interesting stuff happen there. The same thing may happen with databases and rust.

And you didn't address my example, which was all of those "-devel" packages you need to install to get all of those libraries that so much software depends on: libssl, libjpeg, etc.

"Rust throws the baby out with the bathwater and tries to pressure others into thinking that they are in this market."

And this has what ill effect?

[tom_mellior]

This will be my last post in this subthread because I think most of my points have now been made several times...

> New people are getting involved in OS development in rust, for instance.

Tiny market. Expanding it to be slightly less tiny doesn't make it non-tiny. More importantly, positioning Rust as an operating systems programming language will not get people to use it for more general application programming.

> The same thing may happen with databases and rust.

Also a tiny market. Also, not sure how wrestling with the Rust compiler will advance database theory or practice. Even more importantly, the implication (in the context of the thread) that it's impossible to write a database system in a GC language is false. To optimize the implementation, you may probably want to avoid GC in the innermost hot parts. That would be possible with the hypothetical Rust-with-optional-GC I mentioned above.

> And you didn't address my example, which was all of those "-devel" packages you need to install to get all of those libraries that so much software depends on: libssl, libjpeg, etc.

I don't know what exactly you mean by that since you even need those packages for C programming, and you need them (or something equivalent to the headers they provide) for Rust, but yes, language interoperability is hard, and yes, some language runtimes make it harder than it should ideally be.

> And this has what ill effect?

Many people will read stuff about OS kernels and database systems and vaguely elitist but never concretized ramblings about "systems programming", coupled with "OMG, everything must always be super-fast at the expense of programmer productivity" and decide that they are not in this market. And then they will keep using Python. Or, just to rub it in, Go for "systems programming" like NTPsec. <shrug> I never said that that's a bad thing; I just said that this will not drive more general Rust adoption.

[pkolaczk]

Well, even though I'm totally for using a modern GC when I can, implementing an efficient GC (low pause, high throughput) requires a lot of effort and special hardware. This is still not available for a number of platforms, particularly the tiny ones, where you may only dream of things like memory virtualization. Also, reference counting may not be as bad as you think when objects are never shared between threads and when you have a smart compiler that can elide most of redundant increments/decrements.