Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sorry must say this, can we have a version of golang without GC? #39231

gitmko0 opened this issue May 24, 2020 · 1 comment

Sorry must say this, can we have a version of golang without GC? #39231

gitmko0 opened this issue May 24, 2020 · 1 comment


Copy link

@gitmko0 gitmko0 commented May 24, 2020

Sorry must say this, can we have a version of golang without GC?

Maybe a branch called GoX 1.0 without garbage collection and focus purely on speed.

A lot of people are migrating to rustlang coz of this. I truly wish not to do so too (very tempted for that extra 14-25% speed improvement and ~15% memory reduction) BUT rust is "overly" complicated and too slow to compile.

I propose a gc-less branch called GoX with the following focus:

  1. The syntax and keywords of the golang programming language remain BUT only without the GC part and we don't have to do it "unsafely".
  2. A well thought of structure so we can migrate / rewrite from current GC version to the GCless one easily / easier.
  3. A plan whereby the GoX can be converted to wasm easily with/without TinyGo.

I've wrote go for 3 years now and ALL my code logic is working fine. However, the speed improvement possibility using rust is overly tempting. (i've sort of stretched the limits of golang performance improvement... sort of extreme but i know rust can do ~15% better CPU efficiency and 15% lesser memory compared to an extreme optimized golang for mid size programs. the more you write, the slower it should get once more memory is used. I've tried running golang using 50GB memory. the "stop the world" spike is definitely there once a while but not a very serious thing so far. It's more of the wasm output which I'm talking about for TinyGo etc., also because of cloud functions, gcless should be "better"). I understand the rationale to defend continual using GC golang and i've hand fine tuned gc problem etc. too so this is not about how to write go code by minimizing gc.

About to move to rust like a lot of people but after reviewing all the past 3 years code I've written, if we can just have a GoX (without GC), I don't need to translate my code to rust.

Please make this a real possibility. I'm sure within 2 years can be achieved. And once so, even if 5% lesser cpu efficiency and 5% lesser memory compared to rust, that'll be extremely good. My problem with golang is nothing but GC, which slows things down and when used with TinyGo conversion to wasm, the GC code bloats the wasm output.

Is this something that the golang community is looking at? I know plenty people write unsafe golang code to do away with the gc issue. Does not matter at all. GoX should be extreme speed efficiency of golang. So means GC must go.

With reference to #29147, quoted:

Garbage collection: as mentioned before there is no way to avoid this in the Go language, but how this is implemented is an implementation choice and not a language choice.

I don't think so. If the community wants a GCless golang, we can make it happen. It's just a programming language. Simplistic point of view, just "Turn off GC", "remove GC", "let GC run once every 10,000 years"... right?

GoX <- will this be happening in 5 years? Coz I don't want to learn rust or another language more.
If yes in 5 years time, I will not learn anything more but prepare my golang codebase for conversion. If no, then... no choice but rust. What's the feedback? Appreciate the work on golang. It's definitely a great language to work with (for those who know what they are doing).

Copy link

@ALTree ALTree commented May 24, 2020

"Go without GC" wouldn't be Go, it would be a different language. It's fine to want a language without a garbage collector, but this is the Go issue tracker, and the people around here are working on Go, and not on a different (hypothetical) language with Go-like syntax and no GC.

I suggest reading the Why do garbage collection? Won't it be too expensive? FAQ to understand the background of this decision.

I'm closing this issue since I don't think it is in scope for the Go issue tracker.

@ALTree ALTree closed this May 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.