Wasm GC does not offer weak refs or finalizers at this point: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Pos...
In C# now beats Rust on WASM sizeWebAssembly
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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:56:56 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
68 sources> Then C# came and said
It's worse than that. The WASM GC standards team was warned in advance that the proposal wouldn't work for .NET, and they moved forward with it anyway:
https://github.com/WebAssembly/gc/issues/77
They were also warned about Go (though I'm not sure if they ever actually consulted with golang devs):
https://github.com/WebAssembly/gc/issues/36
More links:
https://github.com/dotnet/runtime/issues/94420
https://github.com/golang/go/issues/63904
In Windows 11's built-in Weather app wastes more than 1 GB of RAMLinks to discussions about why WASM GC in its current state is not suitable for .NET: https://github.com/WebAssembly/gc/issues/77
What should be improved: https://github.com/dotnet/runtime/issues/94420
In GC and Exceptions in WasmtimeDefinitely don't recommend that since it works when it does and doesn't otherwise. Most users will not end up happy trying to make it work since the alternative is more common.
This isn't a fault of TinyGo itself, it is just targeting a space that doesn't really prioritize embedded but got picked up for that just because. But without fixing this Wasm ecosystem issue, compiling Go to Wasm will never be a real thing.
https://github.com/WebAssembly/gc/issues/59
In Go on Embedded Systems and WebAssemblyGo and even TinyGo aren't a great fit for Wa because they have to bring along their own runtime including a GC. Go can't use WasmGC because it lacks support for interior pointers and unboxed heap primitives: https://github.com/WebAssembly/gc/issues/59
So you'll never get Go Wasm binary sizes down to something reasonable, alas.
In Local First HtmxThose changes affect the .NET runtime, designed for real computers. This does not preclude the existence of a special runtime designed for Wasm with WasmGC support.
The .NET team appears to be aware of WasmGC [0], and they have provided their remarks when WasmGC was being designed [1].
[0] https://github.com/dotnet/runtime/issues/94420
[1] https://github.com/WebAssembly/gc/issues/77
In What .NET 10 GC changes mean for developersC# cannot be compiled to WASM GC yet: https://github.com/WebAssembly/gc/issues/77.
In WASM 3.0 CompletedI don't think the GC in this version has the features required to enable a C# runtime on top of it yet: https://github.com/WebAssembly/gc/issues/77
I wonder what language this GC can actually be used for at this stage?
In WASM 3.0 CompletedI can't find the actual decision, but there was some discussion here: https://github.com/WebAssembly/gc/issues/77
Microsoft later in 2023 said that that discussion "is the current state we are in. We will keep eye on wasm GC in the future."
edit: found a more concrete statement https://github.com/dotnet/runtime/issues/94420
In Popcorn: Run Elixir in WASMwith the wasm-gc proposal you get access to structs and arrays: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...
with the component model's wit you get higher level types like enums, option, result and generics: https://component-model.bytecodealliance.org/design/wit.html
In WASM 2.0Here's the issue which gives an overview of the problems: https://github.com/WebAssembly/gc/issues/77
Further discussion can be found here: https://github.com/dotnet/runtime/issues/94420
Turning off destructors will not help even a little because the biggest pain points are support for byref pointers and insufficient degree of control over object memory layout.
In Ask HN: A retrofitted C dialect?For the audience that would be looking to use the WASM Component Model, and not be an infrastructure implementer of it, whether or not they meet some definition of a method, the component model does define things called resources [1] that have "methods". You'll hold a "handle" to it like you would in your own programming language with the expected drop and/or GC semantics (once implemented [2]) because code is generated to access it like any other FFI like C/C++.
With that in mind, the other confusing thing one may come across is composition vs linking within your WASM runtime that supports the Component Model. When you hear "composition" think of compile-time merging of libraries such that the bundle may have less unresolved dependencies of WASM code/implemented component interfaces. Anything unresolved needs to be linked at runtime with
Read the rest
your WASM runtime of choice, like wasmtime [3]. Pretty interesting reading/potential after reading if you ask me -- sounds like you could implement something like a custom Java classloader hierarchy [4].
But I'd agree with a statement saying it is still a long way for general usage.
[1] https://github.com/WebAssembly/component-model/blob/5a34794d...
[2] https://github.com/WebAssembly/gc
[3] https://github.com/bytecodealliance/wasmtime/blob/ba8131c6bf...
[4] https://www.digitalocean.com/community/tutorials/java-classl...
This post might help:
https://v8.dev/blog/wasm-gc-porting
See in particular the "getting started" section near the end:
https://v8.dev/blog/wasm-gc-porting#getting-started
At a lower level the overview in the WasmGC github repo is very good:
https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...
In Google Sheets ported its calculation worker from JavaScript to WasmGCWasm-GC isn’t compatible with .NET allowing references to fields among other issues. So I doubt that we will see integration soon
https://github.com/WebAssembly/gc/issues/77
In .NET BlazorIt may take some time for WasmGC to be usable by .NET. Based on the discussions the first version of WasmGC does not have a good way to handle a few .NET specific scenarios, and said scenarios are "post-post-mvp". [0]
My concern, of course, is that there is not much incentive for those features to be added if .NET is the only platform that needs them... at that point having a form of 'include' (to where a specific GC version can just be cached and loaded by another WASM assembly) would be more useful, despite the pain it would create.
[0] - https://github.com/WebAssembly/gc/issues/77
In Bringing garbage collected programming languages efficiently to WebAssemblyShowing the 15 most recent of 68 sources. Enable JavaScript to search and browse every indexed mention.