<story><title>Why Go is doomed to succeed</title><url>https://texlution.com/post/why-go-is-doomed-to-succeed/</url></story><parent_chain><item><author>vezzy-fnord</author><text>Go is doomed to succeed because it extends the mental model of C with a concurrency model that finds a decent compromise between power and ease of use, makes the typing less prone to subversion, adds memory safety via GC, uses a structural subtyping system through interfaces that brings many OO-like benefits while still keeping to the C struct way of thinking, first-class functions, various syntactic rough edges cleaned up and so forth.&lt;p&gt;Because the Unix system programming world (and POSIX particularly) is very much built with the conventions and semantics of C in mind, most serious POSIX programming outside of C means you have to deal with painful FFIs, lousy wrappers, overly abstracted APIs that hide details like certain lower level flags and so forth. Some are better at this than others, of course (OCaml is one of the better ones)... but, nonetheless.&lt;p&gt;So it&amp;#x27;s unsurprising that many infrastructure developers are jumping to Go. There&amp;#x27;s just enough new things to incentivize a switch, but not &lt;i&gt;too&lt;/i&gt; much that it dissuades from it.</text></item></parent_chain><comment><author>tptacek</author><text>I&amp;#x27;m a 90&amp;#x27;s C programmer and a Golang programmer now, and while there&amp;#x27;s some truth to this, it&amp;#x27;s reductive. A 2000s-era C programmer would not write socket code that worked the way net.Conn does. While C code gave us the &amp;quot;pipes and filters&amp;quot; abstraction of Unix, they are not an idiom in C code --- in fact, Golang&amp;#x27;s reader&amp;#x2F;writer interfaces feel more like a refinement of Java than a modernization of C.&lt;p&gt;Golang feels very much like an offspring of Java and Python to me.</text></comment>
<story><title>Why Go is doomed to succeed</title><url>https://texlution.com/post/why-go-is-doomed-to-succeed/</url></story><parent_chain><item><author>vezzy-fnord</author><text>Go is doomed to succeed because it extends the mental model of C with a concurrency model that finds a decent compromise between power and ease of use, makes the typing less prone to subversion, adds memory safety via GC, uses a structural subtyping system through interfaces that brings many OO-like benefits while still keeping to the C struct way of thinking, first-class functions, various syntactic rough edges cleaned up and so forth.&lt;p&gt;Because the Unix system programming world (and POSIX particularly) is very much built with the conventions and semantics of C in mind, most serious POSIX programming outside of C means you have to deal with painful FFIs, lousy wrappers, overly abstracted APIs that hide details like certain lower level flags and so forth. Some are better at this than others, of course (OCaml is one of the better ones)... but, nonetheless.&lt;p&gt;So it&amp;#x27;s unsurprising that many infrastructure developers are jumping to Go. There&amp;#x27;s just enough new things to incentivize a switch, but not &lt;i&gt;too&lt;/i&gt; much that it dissuades from it.</text></item></parent_chain><comment><author>aaggarwal</author><text>I have never used Go before. From the sound of it, it looks like Go hits a sweet spot between C and Java? and of course the Google support is a major factor for a possible success.</text></comment>