[DonFromWyoming]

Go is unsuitable as a replacement for C because it is garbage collected. End of discussion.

Rust is unsuitable as a replacement for C because its memory management is poorly thought out (ie. its a joke). Here's the relevant paragraphs from the Rust FAQ. Really?

"Rust avoids the need for GC through its system of ownership and borrowing, but that same system helps with a host of other problems, including resource management in general and concurrency.

For when single ownership does not suffice, Rust programs rely on the standard reference-counting smart pointer type, Rc, and its thread-safe counterpart, Arc, instead of GC.

We are however investigating optional garbage collection as a future extension. The goal is to enable smooth integration with garbage-collected runtimes, such as those offered by the Spidermonkey and V8 JavaScript engines. Finally, some people have investigated implementing pure Rust garbage collectors without compiler support."

[Manishearth]

> For when single ownership does not suffice, Rust programs rely on the standard reference-counting smart pointer type, Rc, and its thread-safe counterpart, Arc, instead of GC.

This is a library thing, not a language thing.

If single ownership is enough for you, go ahead and use it. But if you need a different memory management strategy, that is available too.

Rust, the language, provides a single clear memory management strategy. It also provides the ability to design your own abstractions for different strategies, and implements some of these in the stdlib.

C/C++ have refcounting and GC libraries too. Does that make them a joke?

[steveklabnik]

You don't describe why you think it's a joke.

[DonFromWyoming]

Steve - did you read the FAQ? They really don't know what direction to go. At least Swift stuck with ARC, being a necessity as they were tasked with merging Swift with the Objective-C runtime for interoperability. Rust's multiple methods of memory management makes it strange, at best, for programmers to decide how to build a program or an API. Are the owners of Rust planning on adding a GC? Really?

[steveklabnik]

I helped edit the FAQ.

  > They really don't know what direction to go.

That's incorrect. A systems language needs to be flexible; it cannot dictate that everyone must do something a single way.

Does the presence of libraries for refcounting or even GC in C (most famously Boehm) mean that C has an incoherent story around memory?

  > Rust's multiple methods of memory management makes it strange, at best,
  > for programmers to decide how to build a program or an API.

It does not. Each has their place. Need single ownership? Use a type that has it. Need multiple ownership? Use a type that has it.

  >  Are the owners of Rust planning on adding a GC? Really?

Not really. There's a few different things here: first is integrations with other systems that have a GC. As an example, consider Servo: it has to interact with Spidermonkey's GC, since it interfaces with JavaScript code. Consider the opposite system: Rust embedded inside of another language, let's say Python, where you want to be able to talk to Python's GC for various reasons.

The second is something like Bohem: if a system wants to use GC for some reason, they have an interface to add a GC'd type. But Rust proper, the language, will not have GC. It's completely contradictory to the goals of the language.

[Manishearth]

> Are the owners of Rust planning on adding a GC? Really?

To address this specifically: Current plans for Rust are mostly along the lines of adding the bare necessities in the stdlib to allow GC implementations to be written.

There are mostly-niche use-cases for having a GC in Rust. I've written some of the motivation here[1] (note that that blog post is about a pure library GC independent of Rust, which is different from what is planned; but the motivations are similar).

One major use case is if you want to talk to a language which has a GC. Say you're writing a native extension to a Ruby or Node and want to deal with the GCd types within Rust code in a safe way without pausing the GC. Or if you're writing an interpreter for a GCd language. Or you're writing some code that deals with complicated cyclic graph-like datastructures.

These are all pretty niche, but the workarounds in these cases aren't pretty so it's nice to have some form of GC capabilities in Rust. This is not a price you pay by default, and it's not something that affects anyone but the people who need these types. It will probably take the form of some low level APIs that use LLVM stack rooting to collect roots, and some traits in the stdlib, which can be used by an independent GC library (not part of the stdlib) or a language bindings library (also not part of the stdlib).

Rust itself will never get a GC as part of the language.

[1]: http://manishearth.github.io/blog/2015/09/01/designing-a-gc-...

[Manishearth]

Steve wrote the FAQ and most of the docs

[steveklabnik]

I would hesitate to say I write the FAQ these days; after Brian's efforts to revamp it, it was VERY MUCH a community effort.

[caconym_]

This post is a joke without a material argument to support your claim.