Wasm-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 BlazorWebAssembly
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, 2:04:58 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 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
14 sourcesIt 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 WebAssemblyFor now I think that's true. But there are plans to add features like interior pointers to WasmGC, that could allow a lot more eventually:
https://github.com/WebAssembly/gc/blob/main/proposals/gc/Pos...
In Bringing garbage collected programming languages efficiently to WebAssemblyThe WASM-GC support is intentionally kept as simple as possible, see https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP... . Building a "universal" or "generic" VM supporting many languages on an equally seamless basis is explicitly not a goal of WASM-GC; it is expected that each implementation might require its own hacks and special semantics on top of the basic support WASM provides, but this is okay because FFI/cross-language interop is seen as an entirely separate issue.
In Bringing garbage collected programming languages efficiently to WebAssemblyYes, that's definitely true: a single GC will not be optimal for everything, or even possible. Atm interior pointers are not supported at all, for example, but they are on the roadmap for later:
https://github.com/WebAssembly/gc/blob/main/proposals/gc/Pos...
What launched now is enough WasmGC to support a big and useful set of languages (Java, Kotlin, Dart, OCaml, Scheme), but a lot more work will be required here!
In WasmGC – Run GC languages such as Kotlin, Java in Chrome browserGC proposal is from 2018: https://github.com/WebAssembly/proposals/issues/16 and there’s code: https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...
Seems like an awefully long time for progress to be made, given all the possibilities it would unlock.
In Learn WebAssembly by writing small programs> I would put money JS staying as is and WASM will be the web story moving forward
Ditto.
WASM needs just 1 piece to be pretty much widely generalizable, GC. Once that happens, things will get pretty exciting. Access to a platform garbage collector will allow pretty much any language imaginable ship to WASM with some pretty minimal runtime overhead.
And GC for WASM is due to hit pretty soon. I'm looking forward to the revival of Applets :D
[1] https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP...
In Dart 3.1 and a retrospective on functional style programming in DartMy understanding is that the main limitation is technical. WASM doens't do GC or the host system calling conventions and cannot interact directly with object from Javascript because of this. However, this is being worked[0] on and will be solved eventually. Even without this, the performance overhead of bridging to JS is low enough that WASM frameworks can beat out React.
0: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...
In Douglas Crockford on JavaScriptAFAIK garbage collected 'objects' are completely separate from regular WASM heap allocations and tracked directly by the WASM VM (I may be wrong though, but details are here: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...)
In A world to win: WebAssembly for the rest of usOption 1 - Webassembly without a built-in garbage collector - exists today. You can compile Go or C# to WASM today, and it will output a WASM module with an embedded garbage collector.
There's a draft proposal to add a built in garbage collector (option 2) to WASM. I have no idea what the current status is - maybe someone involved can chime in. I suspect some version of the WASM GC spec will land eventually.
When it does, languages like Go, C# and Java should start to become competitive with javascript as frontend web languages.
https://github.com/WebAssembly/gc
In A world to win: WebAssembly for the rest of usIt seems this is the current doc about the GC:
https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP...
Looking at the "instructions" section... is it going to be slow again, bringing back the speed of interpreted code to the WASM?
In A world to win: WebAssembly for the rest of usSorry about that I was saying in kidding tone. We're all good.
Here is the wasm binary size number (2019): https://stackoverflow.com/questions/55135927/how-do-webassem...
I didn't bookmark Zig and other for the number, it's over here and there on HN threads and Github issues.
---
I think you conflated "wasm binary size from AssemblyScript" with AssemblyScript size itself, that's why you brought up React to compare with AssemblyScript. AssemblyScript doesn't compete with React. And comparing React with the others is also tricky because of paradigm difference. React view and logic are very coupled. Compile-to-wasm langs only compete with js/ts part excluding the DOM part .. at least for now because wasm can't even share string ref right now (the "stringref" proposal is currently phase-1 ), let alone DOM access.
Wasm-gc proposal is already i
Read the rest
n phase-3. I think languages that used to also compile their runtime with app code could be smaller because wasm host manage collect the garbage for you in terms of "struct" and "array" (you can check out https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...)
I assume that's one of the parts of the work done at https://github.com/WebAssembly/gc - not happening any soon yet, but it'll eventually be done.
In Kernel-WASM: Sandboxed kernel mode WebAssembly runtime for Linux