Go memory ballast: How I learnt to stop worrying and love the heap

Re:Go memory ballast: How I learnt to stop worrying and love... by sagichmal on Monday December 02, 2019 @02:30PM (#21685913)

It's Go's position that the language (and/or runtime) should make this unnecessary for the vast majority of use cases, I'm not sure what they're targeting exactly but I'm sure it's 99% or more. The resulting lack of knobs is actually a feature, and one I'm very glad to have.

I'm also happy to make my code less allocation-happy or more GC-friendly in the extremely rare circumstances when it matters. Like this article!

But I think we probably just work in different environments.

[ Parent | on HN ]

Re:Go memory ballast: How I learnt to stop worrying and love... by erik_seaberg on Monday December 02, 2019 @04:36PM (#21687242)

I would much rather make the concise and clear implementation perform better, than take the readability hit and risk of mistakes from rewriting it (probably more than once).

[ Parent | on HN ]

Re:Go memory ballast: How I learnt to stop worrying and love... by sagichmal on Monday December 02, 2019 @06:57PM (#21688449)

This is sensical for application code, but I think a bad compromise for a language runtime.

[ Parent | on HN ]

Re:Go memory ballast: How I learnt to stop worrying and love... by apta on Tuesday December 03, 2019 @09:31AM (#21692501)

The golang position is to pretend complexity doesn't exist until it becomes a problem (this already happened before for example with the clock issue). This approach is already evident in the overly simplistic design of the language, which ends up pushing complexity into the code, and causing problems with it.

[ Parent | on HN ]