Aleph lacked GC, which Rob Pike considered the main reason for its implementation failure on Plan 9, and initially bounds checking was also missing.
Two key design difference from Go and its two predecessors.
Dis is an implementation detail, Go could offer the same dynamism with AOT toolchain, as proven by other languages with ahead of time toolchains available.
So does Rust. Rust is 'smarter' than Limbo, in that it can avoid using its GC in a lot of cases (but not all, hence why it still has GC to fall back on when necessary), but, I mean, that discovery was the reason for why Rust was created. Limbo was already there otherwise. Every new language needs to try to add something into the mix.
Still, the thoughts were in common, even though the final solution didn't end up being exactly the same.
Rust does not have a garbage collector in any way or form. It's just automatic memory like we're used to (e.g., stack in C++), with the compiler injecting free/drop when an object goes out of scope.
What Rust brings is ownership with very extensive lifecycle tracking, but that is a guard rail that gives compile-time failures, not something that powers memory management.
(If you consider the presence of Rc<T> to make Rust garbage collected, then so is C garbage collected as developers often add refcounting to their structs.)
> so is C garbage collected as developers often add refcounting to their structs.
Absolutely, C also can use a garbage collector. Obviously you can make any programming language do whatever you want if you are willing to implement the necessary pieces. That isn't any kind of revelation. It is all just 1s and 0s in the end. C, however, does not come with an expectation of it being provided. For all practical purposes you are going to have to implement it yourself or use some kind of third-party solution.
The difference with Limbo and Rust is that they include reference counting GCs out of the box. It is not just something you have the option of bolting onto the side if you are willing to put in the effort. It is something that is already there to use from day one.
It is not C using the garbage collector - it is you writing a garbage collector in C. The application or library code you develop with the language is not itself a feature of the language, and the language you wrote the code in is not considered to be "using" your code.
Rust and C are unaware of any type of garbage collection, and therefore never "use" garbage collection. They just have all the bells and whistles to allow you to reference count whatever type you'd like, and in case of Rust there's just a convenient wrapper in the standard library to save you from writing a few lines of code. However, this wrapper is entirely "bolted onto the side": You can write your own Rc<T>, and there would be no notable difference to the std version.
So no, neither Rust nor C can use a garbage collector, but you can write code with garbage collection in any feature-complete language. This is importantly very different from languages that have garbage collection as a feature, like Limbo, Go, JavaScript, etc.
I would say that RC is GC, yes, as it is most definitely technically true. But it was pjmlp who suggested it originally (Limbo also uses reference counting), so we have clear evidence that others also see reference counting as being GC. We wouldn't have a discussion here otherwise.
While RC is a GC algorithm, chapter 5 from GC handbook, it doesn't count when it isn't part of the type system because then it becomes optional and not part of the regular use of the programming language.
Additionally Limbo's GC is a bit more complicaticated than a plain add_ref()/release() pair of library calls.
However the influence is quite clear, plus the Oberon-2 style methods and SYSTEM package.