<story><title>Generics can make your Go code slower</title><url>https://planetscale.com/blog/generics-can-make-your-go-code-slower</url></story><parent_chain><item><author>no_circuit</author><text>The article is from a database company, so I&amp;#x27;ll assume that approximates the scope. My scope for the GC discussion would include other parts that could be considered similar software: cluster-control plane (Kubernetes), other databases, and possibly the first level of API services to implement a service like an internal users&amp;#x2F;profiles or auth endpoints.&lt;p&gt;The tricky thing is GC works most of the time, but if you are working at scale you really can&amp;#x27;t predict user behavior, and so all of those GC-tuning parameters that were set six months ago no longer work properly. A good portion of production outages are likely related to cascading failures due to too long GC pauses, and a good portion of developer time is spent testing and tuning GC parameters. It is easier to remove and&amp;#x2F;or just not allow GC languages at these levels in the first place.&lt;p&gt;On the other hand IMO GC-languages at the frontend level are OK since you&amp;#x27;d just need to scale horizontally.</text></item><item><author>reikonomusha</author><text>I have a slightly contrary opinion. Systems software is a very large umbrella, and much under that umbrella is not encumbered by a garbage collector whatsoever. (To add insult to injury, the term&amp;#x27;s definition isn&amp;#x27;t even broadly agreed upon, similar to the definition of a &amp;quot;high-level language&amp;quot;.) Yes, there are some systems applications where a GC can be a hindrance in practice, but these days I&amp;#x27;m not even sure it&amp;#x27;s a majority of systems software.&lt;p&gt;I think what&amp;#x27;s more important for the systems programmer is (1) the ability to inspect the low-level behavior of functions, like through their disassembly; (2) be reasonably confident how code will compile; and (3) have some dials and levers to control aspects of compiled code and memory usage. All of these things can and are present, not only in some garbage collected languages, but also garbage-collected languages with a dynamic type system!&lt;p&gt;Yes, there are environments so spartan and so precision-oriented that even a language&amp;#x27;s built-in allocator cannot be used (e.g., malloc), in which case using a GC&amp;#x27;d language is going to be an unwinnable fight for control. But if you only need to do precision management of a memory that isn&amp;#x27;t pervasive in all of your allocation patterns, then using a language like C feels like throwing the baby out with the bath water. It&amp;#x27;s very rarely &amp;quot;all or nothing&amp;quot; in a modern, garbage-collected language.</text></item><item><author>nvarsj</author><text>I&amp;#x27;d argue that golang is inherently not a systems language, with its mandatory GC managed memory. I think it&amp;#x27;s a poor choice for anything performance or memory sensitive, especially a database. I know people would disagree (hence all the DBs written in golang these days, and Java before it), but I think C&amp;#x2F;C++&amp;#x2F;Rust&amp;#x2F;D are all superior for that kind of application.&lt;p&gt;All of which is to say, I don&amp;#x27;t think it matters. Use the right tool for the job - if you care about generic overhead, golang is not the right thing to use in the first place.</text></item></parent_chain><comment><author>EdwardDiego</author><text>&amp;gt; A good portion of production outages are likely related to cascading failures due to too long GC pauses, and a good portion of developer time is spent testing and tuning GC parameters&lt;p&gt;After 14 years in JVM dev in areas where latency and reliability are business critical, I disagree.&lt;p&gt;Yes, excessive GC stop the world pauses can cause latency spikes, and excessive GC time is bad, and yes, when a new GC algorithm is released that you think might offer improvements, you test it thoroughly to determine if it&amp;#x27;s better or worse for your workload.&lt;p&gt;But a &amp;quot;good portion&amp;quot; of outages and developer time?&lt;p&gt;Nope. Most outages occur for the same old boring reasons - someone smashed the DB with an update that hits a pathological case and deadlocks processes using the same table, a DC caught fire, someone committed code with a very bad logical bug, someone considered a guru heard that gRPC was cool and used it without adequate code review and didn&amp;#x27;t understand that gRPC&amp;#x27;s load balancing defaults to pick first, etc. etc.&lt;p&gt;The outages caused by GC were very very few.&lt;p&gt;Outages caused by screw-ups or lack of understanding of subtleties of a piece of tech, as common as they are in every other field of development.&lt;p&gt;Then there&amp;#x27;s the question of what outages GCed languages _don&amp;#x27;t_ suffer.&lt;p&gt;I&amp;#x27;ve never had to debug corrupted memory, or how a use after free bug let people exfiltrate data.</text></comment>
<story><title>Generics can make your Go code slower</title><url>https://planetscale.com/blog/generics-can-make-your-go-code-slower</url></story><parent_chain><item><author>no_circuit</author><text>The article is from a database company, so I&amp;#x27;ll assume that approximates the scope. My scope for the GC discussion would include other parts that could be considered similar software: cluster-control plane (Kubernetes), other databases, and possibly the first level of API services to implement a service like an internal users&amp;#x2F;profiles or auth endpoints.&lt;p&gt;The tricky thing is GC works most of the time, but if you are working at scale you really can&amp;#x27;t predict user behavior, and so all of those GC-tuning parameters that were set six months ago no longer work properly. A good portion of production outages are likely related to cascading failures due to too long GC pauses, and a good portion of developer time is spent testing and tuning GC parameters. It is easier to remove and&amp;#x2F;or just not allow GC languages at these levels in the first place.&lt;p&gt;On the other hand IMO GC-languages at the frontend level are OK since you&amp;#x27;d just need to scale horizontally.</text></item><item><author>reikonomusha</author><text>I have a slightly contrary opinion. Systems software is a very large umbrella, and much under that umbrella is not encumbered by a garbage collector whatsoever. (To add insult to injury, the term&amp;#x27;s definition isn&amp;#x27;t even broadly agreed upon, similar to the definition of a &amp;quot;high-level language&amp;quot;.) Yes, there are some systems applications where a GC can be a hindrance in practice, but these days I&amp;#x27;m not even sure it&amp;#x27;s a majority of systems software.&lt;p&gt;I think what&amp;#x27;s more important for the systems programmer is (1) the ability to inspect the low-level behavior of functions, like through their disassembly; (2) be reasonably confident how code will compile; and (3) have some dials and levers to control aspects of compiled code and memory usage. All of these things can and are present, not only in some garbage collected languages, but also garbage-collected languages with a dynamic type system!&lt;p&gt;Yes, there are environments so spartan and so precision-oriented that even a language&amp;#x27;s built-in allocator cannot be used (e.g., malloc), in which case using a GC&amp;#x27;d language is going to be an unwinnable fight for control. But if you only need to do precision management of a memory that isn&amp;#x27;t pervasive in all of your allocation patterns, then using a language like C feels like throwing the baby out with the bath water. It&amp;#x27;s very rarely &amp;quot;all or nothing&amp;quot; in a modern, garbage-collected language.</text></item><item><author>nvarsj</author><text>I&amp;#x27;d argue that golang is inherently not a systems language, with its mandatory GC managed memory. I think it&amp;#x27;s a poor choice for anything performance or memory sensitive, especially a database. I know people would disagree (hence all the DBs written in golang these days, and Java before it), but I think C&amp;#x2F;C++&amp;#x2F;Rust&amp;#x2F;D are all superior for that kind of application.&lt;p&gt;All of which is to say, I don&amp;#x27;t think it matters. Use the right tool for the job - if you care about generic overhead, golang is not the right thing to use in the first place.</text></item></parent_chain><comment><author>throwaway894345</author><text>&amp;gt; The tricky thing is GC works most of the time, but if you are working at scale you really can&amp;#x27;t predict user behavior, and so all of those GC-tuning parameters that were set six months ago no longer work properly. A good portion of production outages are likely related to cascading failures due to too long GC pauses, and a good portion of developer time is spent testing and tuning GC parameters. It is easier to remove and&amp;#x2F;or just not allow GC languages at these levels in the first place.&lt;p&gt;Getting rid of the GC doesn&amp;#x27;t absolve you of the problem, it just means that rather than tuning GC parameters, you&amp;#x27;ve encoded usage assumptions in thousands of places scattered throughout your code base.</text></comment>