<story><title>Why Go and Not Rust?</title><url>https://kristoff.it/blog/why-go-and-not-rust/</url></story><parent_chain><item><author>cletus</author><text>For the record, I like Go. I also like Rust. But I really see them as being aimed at different markets. Go is a better Python&amp;#x2F;Java. Rust is a better C&amp;#x2F;C++. The interesting thing about Go is Rob Pike envisioned it as a systems programming language but any language with GC is a complete nonstarter as a systems programming language.&lt;p&gt;So as for the author&amp;#x27;s pretext (writing some tool in Go), personally my view is &amp;quot;why not?&amp;quot; not &amp;quot;why not Rust?&amp;quot;. If someone had written that same tool in Rust I wouldn&amp;#x27;t be saying &amp;quot;why not Go?&amp;quot;. Whatever floats your boat.&lt;p&gt;But here is the one part where I disagree with the author:&lt;p&gt;&amp;gt; Go is unapologetically simple&lt;p&gt;It is not as simple as it seems, just like every GC language out there. I find Go advocates in particular seem to dismissive of any GC complexities or downsides. Maybe because many of them just don&amp;#x27;t have the background in dealing with this from years of Java.&lt;p&gt;I worked on a team at Google that wrote and maintained a project using Go. Note that I never wrote anything for this project so my experience was second hand but close second hand.&lt;p&gt;One thing I remember was the Go binary blowing up on memory limits (10GB+) in production. Some debugging found there to be millions of Go channels (IIRC) that needed to be cleaned up. For whatever reason the GC didn&amp;#x27;t clean them up, possibly because of a non-obvious dangling reference, possibly not.&lt;p&gt;Anything can have bugs obviously. It&amp;#x27;s just a myth that GC is a silver bullet is my point.&lt;p&gt;There was a guy who worked on the Go team (David Crawshaw) who&amp;#x27;d stop by every now and again. Occasionally I&amp;#x27;d get into debates with him about Go and GC. It&amp;#x27;s from these that I established my general observations of Go pundits:&lt;p&gt;1. Full GC pauses and GC in general are totally not a problem in Go.&lt;p&gt;2. If they were, they&amp;#x27;re totally going to be fixed in Go 1.N+1 where N = the current version of Go.&lt;p&gt;(At the time, the argument David made was that Go&amp;#x27;s STW GC pauses were sub-millisecond so totally not a problem).</text></item></parent_chain><comment><author>zeeboo</author><text>The memory leak due to channels not being cleaned up was almost certainly because goroutines themselves are not garbage collected when they&amp;#x27;re forever blocked. In other words, `ch := make(chan int); go func() { ch &amp;lt;- 1 }()` is a memory leak. This is analogous to spawning a thread that deadlocks by attempting to lock a mutex twice, and has nothing to do with garbage collection.&lt;p&gt;About the GC pauses, check out the latency graphs at &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;ixy-languages&amp;#x2F;ixy-languages&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;ixy-languages&amp;#x2F;ixy-languages&lt;/a&gt; (being careful not to mix up the Javascript and Go lines). Go handily beat every other garbage collected language in latency, and is in the same ballpark as the two non-GC languages (Rust and C). The peak tail latency times are measured in the hundreds of microseconds even at the highest loads tested, so I think the pundits may have a point.</text></comment>
<story><title>Why Go and Not Rust?</title><url>https://kristoff.it/blog/why-go-and-not-rust/</url></story><parent_chain><item><author>cletus</author><text>For the record, I like Go. I also like Rust. But I really see them as being aimed at different markets. Go is a better Python&amp;#x2F;Java. Rust is a better C&amp;#x2F;C++. The interesting thing about Go is Rob Pike envisioned it as a systems programming language but any language with GC is a complete nonstarter as a systems programming language.&lt;p&gt;So as for the author&amp;#x27;s pretext (writing some tool in Go), personally my view is &amp;quot;why not?&amp;quot; not &amp;quot;why not Rust?&amp;quot;. If someone had written that same tool in Rust I wouldn&amp;#x27;t be saying &amp;quot;why not Go?&amp;quot;. Whatever floats your boat.&lt;p&gt;But here is the one part where I disagree with the author:&lt;p&gt;&amp;gt; Go is unapologetically simple&lt;p&gt;It is not as simple as it seems, just like every GC language out there. I find Go advocates in particular seem to dismissive of any GC complexities or downsides. Maybe because many of them just don&amp;#x27;t have the background in dealing with this from years of Java.&lt;p&gt;I worked on a team at Google that wrote and maintained a project using Go. Note that I never wrote anything for this project so my experience was second hand but close second hand.&lt;p&gt;One thing I remember was the Go binary blowing up on memory limits (10GB+) in production. Some debugging found there to be millions of Go channels (IIRC) that needed to be cleaned up. For whatever reason the GC didn&amp;#x27;t clean them up, possibly because of a non-obvious dangling reference, possibly not.&lt;p&gt;Anything can have bugs obviously. It&amp;#x27;s just a myth that GC is a silver bullet is my point.&lt;p&gt;There was a guy who worked on the Go team (David Crawshaw) who&amp;#x27;d stop by every now and again. Occasionally I&amp;#x27;d get into debates with him about Go and GC. It&amp;#x27;s from these that I established my general observations of Go pundits:&lt;p&gt;1. Full GC pauses and GC in general are totally not a problem in Go.&lt;p&gt;2. If they were, they&amp;#x27;re totally going to be fixed in Go 1.N+1 where N = the current version of Go.&lt;p&gt;(At the time, the argument David made was that Go&amp;#x27;s STW GC pauses were sub-millisecond so totally not a problem).</text></item></parent_chain><comment><author>Crinus</author><text>&amp;gt; but any language with GC is a complete nonstarter as a systems programming language.&lt;p&gt;Check this out: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;www.projectoberon.com&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;www.projectoberon.com&amp;#x2F;&lt;/a&gt;&lt;p&gt;A full system (not just a language, but also custom CPU on FPGA, OS with GUI, applications, etc) where the language is garbage collected. The system has 1MB of RAM (by default). Note that the garbage collector is implemented entirely in the language itself.&lt;p&gt;The Oberon language was also a big inspiration for Go.</text></comment>