WASM currently does not have a GC but that's precisely why one is needed. Languages that target WASM need to implement their own GC but there's already a proposal to integrate a GC implementation into WASM[1].
[1]: https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...
In Cmm_of_wasm: From WebAssembly to Native Code via the OCaml Back EndWebAssembly
gc
WebAssembly2017–2026
WebAssembly / gc · Archived
gc
Branch of the spec repo scoped to discussion of GC integration in WebAssembly
57Distinct people
68Mentions
0Explicit recommenders
1.1KGitHub stars
What to know before exploring
What it is
Branch of the spec repo scoped to discussion of GC integration in WebAssembly
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
- dotnet/runtime · linked in 5 of the same discussions
- webassembly/proposals · linked in 4 of the same discussions
- webassembly/reference-types · linked in 3 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 7:02:26 AM 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 year68 dated mentions
Observed mentions: 2017-04-29 23:58:05 UTC to 2026-10-21 12:17:44 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
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 |
|---|---|---|---|---|---|
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 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 | 4 | 0 | 4 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 10 | 2 | 8 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 14 | 1 | 13 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 4 | 0 | 4 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
GC Proposal for WebAssembly
This repository is a clone of github.com/WebAssembly/spec/.
It is meant for discussion, prototype specification and implementation of a proposal to add garbage collection (GC) support to WebAssembly.
See the overview for a high-level summary and rationale of the proposal. Note: the concrete details here are out of date.
See the MVP for an up-to-date overview of the concrete language extensions that are proposed for the first stage of GC support in Wasm.
See the Post-MVP for possible future extensions in later stages.
See the modified spec for the completed spec for the first-stage proposal described in MVP.md.
This repository is based on the function references proposal as a baseline and includes all respective changes.
Original README from upstream repository follows...
spec
This repository holds a prototypical reference implementation for WebAssembly,
which is currently serving as the official specification. Eventually, we expect
to produce a specification either written in human-readable prose or in a formal
specification language.
It also holds the WebAssembly testsuite, which tests numerous aspects of
conformance to the spec.
View the work-in-progress spec at webassembly.github.io/spec.
At this time, the contents of this repository are under development and known
to be "incomplet and inkorrect".
Participation is welcome. Discussions about new features, significant semantic
changes, or any specification change likely to generate substantial discussion
should take place in
the WebAssembly design repository
first, so that this spec repository can remain focused. And please follow the
guidelines for contributing.
citing
For citing WebAssembly in LaTeX, use this bibtex file.
Read the full README on GitHubWhat Hacker News says
8 sourcesIt seems to be tracked under/after GC, since that would be a prerequisite.
See https://github.com/WebAssembly/gc/blob/master/proposals/gc/O.... Things like DOM access are specifically mentioned.
In WebAssembly’s post-MVP future> Grain is a language compiled to WebAssembly. So comparing it with either Javascript or Elm is pointless
This ability is a tool and nothing precludes a wasm target for Elm (in fact Evan specifically expressed interest in it: https://github.com/WebAssembly/gc/pull/1#discussion_r1115011...).
Either way, comparing Grain to JS or Elm is anything but pointless, at the end of the day it's competing with them.
In Grain: A strongly-typed functional programming language for the modern webI disagree, I would like WASM impls to offer one that you can optionally leverage for many reasons. Regardless, here is a recent thread that does a good job discussing pros/cons: https://github.com/WebAssembly/gc/issues/36
In The LDC D language compiler can now generate WebAssemblyUnfortunately, as a side effect of it supporting only one memory model, it means that the host code only has a giant memory bag to work with, meaning it needs to reconstruct objects from a giant heap. Currently, anything involving more complex host interaction (say, handles to kernel objects like files) is punted on to either the host-bindings proposal (which has a number of issues and basically was agreed was not a way forward) or the GC proposal (which has even more issues).
The current plan for the GC proposal is to allow skipping having memory heaps at all and talk about things in terms of an object graph and types. See comments here: https://github.com/WebAssembly/gc/issues/32
The important part of a runtime to me is the object model, and wasm basically punted on one for now.
In WebAssembly is more than the webThe downside is that it's extraordinarily difficult to create a single runtime which has a satisfying object and GC model for all parties. The GC proposal which adds such a thing on top of WebAssembly is nowhere near complete and is currently being punted on, with the intermediate solution being host-bindings. And keep in mind that this GC proposal doesn't handle JavaScript's dynamic objects which can change shape at runtime. It only handles ones with known shapes.
It will be a long time for it to be possible for JavaScript to "just be compiled" to WebAssembly while keeping the same performance characteristics, if it ever happens.
[0] https://github.com/WebAssembly/gc/issues/32 has some concerns from language implementors.
In What Does “One JS” Mean in a World of Transpilers?"the WASM GC" only exists as a proposal, and proposals can change before they land. I don't know enough about it to say, and even if I did, it might be invalid by the time things are actually accepted.
See https://github.com/WebAssembly/gc for the current proposal.
In WebAssembly architecture for GoSee the GC proposal: https://github.com/WebAssembly/gc/blob/master/proposals/gc/O.... Here you get structs, arrays, and tuples (that can be used for multiple returns). I am not disappointed that none of these features made the MVP personally.
In TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly