# GC settings, Go now has 2, adopted ours, we should adopt theirs: "Go runtime: 4 years later"

**URL:** <https://discourse.julialang.org/t/gc-settings-go-now-has-2-adopted-ours-we-should-adopt-theirs-go-runtime-4-years-later/87843>\
**Category:** General Usage\
**Created:** [September 26, 2022, 11:08pm UTC](https://discourse.julialang.org/t/gc-settings-go-now-has-2-adopted-ours-we-should-adopt-theirs-go-runtime-4-years-later/87843 "2022-09-26T23:08:47Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [September 26, 2022, 11:08pm UTC](https://discourse.julialang.org/t/gc-settings-go-now-has-2-adopted-ours-we-should-adopt-theirs-go-runtime-4-years-later/87843/1 "2022-09-26T23:08:47Z")

</div>

> **[Go runtime: 4 years later - The Go Programming Language](https://go.dev/blog/go119runtime)**
>
> A check-in on the status of Go runtime development

> ### A new knob
> 
> With Go 1.19 comes an long-requested feature that requires a little extra work to use, but carries a lot of potential: [the Go runtime’s soft memory limit](https://pkg.go.dev/runtime/debug#SetMemoryLimit).
> 
> [Julia 1.9 has such]
> 
> For years, the Go GC has had only one tuning parameter: `GOGC`. `GOGC` lets the user adjust [the trade-off between CPU overhead and memory overhead made by the Go GC](https://pkg.go.dev/runtime/debug#SetGCPercent). For years, this “knob” has served the Go community well, capturing a wide variety of use-cases.
> 
> The Go runtime team has been reluctant to add new knobs to the Go runtime, with good reason: every new knob represents a new _dimension_ in the space of configurations that we need to test and maintain, potentially forever. The proliferation of knobs also places a burden on Go developers to understand and use them effectively, which becomes more difficult with more knobs. Hence, the Go runtime has always leaned into behaving reasonably with minimal configuration.
> 
> So why add a memory limit knob?
> 
> Memory is not as fungible as CPU time. With CPU time, there’s always more of it in the future, if you just wait a bit. But with memory, there’s a limit to what you have.
> 
> The memory limit solves two problems. […]

They allow setting from within the program (at least the setting we have), likely because they ship binaries (with the [GC] runtime), and users to not or wouldn’t know how to set. I do support users being able to set some different things, but should the program also have access, maybe within the limit from the CLI option?