DODougBTX·Nov 5, 2020
There are experiments for a Gc<T> here: https://github.com/Manishearth/rust-gc
In The Fatal Flaw of Ownership SemanticsManishearth
rust-gc
Rust2015–2025
Manishearth / rust-gc
rust-gc
Simple tracing (mark and sweep) garbage collector for Rust
16Distinct people
21Mentions
0Explicit recommenders
1.1KGitHub stars
What to know before exploring
What it is
Simple tracing (mark and sweep) garbage collector for Rust
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 4:00:59 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year21 dated mentions
Observed mentions: 2015-05-18 00:42:25 UTC to 2025-04-28 19:43:03 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 0 | 3 |
What Hacker News says
4 sources> If you make a language GC by default with opt-in ownership, what does your standard library look like?
I could see the opposite working out very well. Having a GC type you can box other types in.
https://github.com/Manishearth/rust-gc
In Assorted Thoughts on Zig and RustFor "non strict mode" meaning bypassing the borrow checker, rust already has that and it's called "unsafe". And if by "non struct mode" you mean not having manual garbage collection then you've already got that either as `::leak` letting you leak memory or various GC implementations like https://github.com/Manishearth/rust-gc/.
In Rust 1.47First of all, Andrei Alexandrescu is not the creator of D.
> With Rust, programmers have to spend most of their mental energy worrying about management of memory, which has largely been automated already.
This is a common misunderstanding. I think the word "automated" is misleading, and suggest that we should look at two phases of memory management: the plan and the execution.
In traditional low-level languages like C, you plan how to manage memory and you write code to execute that plan yourself. Your code may not match the plan, thus all sort of problems ensues.
In languages with GC, you are allowed to not think how to manage memory and GC will execute their own inferred plan... until it is not. At some point you are forced to think how to manage memory and also tune GC and/or code to fit to your belated plan. This point may not be reac
Read the rest
hed (simple scripts) or can be delayed much further (good modern GC), of course, so it still remains very useful.
In (a typical use case of) Rust, you plan how to manage memory but give that plan to the compiler to check if the plan is executed correctly. The compiler also generate code for common executions that you don't have to. So the execution is mostly automated (or rather, delegated), while planning is not.
A common theme here is that you can't avoid at least the planning once you've got past a threshold. If GC would supplant even that planning, you won't need value types at all; isn't that what the generation hypothesis is all about? But many languages with GC but not value types now get them. While it can be argued that Rust's affine typing is not sufficient to capture some common memory management patterns [1], that fact doesn't diminish the value of explicit memory management planning, and thus Rust's.
[1] And I think it is actually true! Indeed, I believe affine typing plus GC can be actually better than affine typing or GC alone (and value types mimic a good subset of this). There are some Rust libraries for tracing GC (e.g. [2]) as a starting point.
[2] https://github.com/Manishearth/rust-gc