<story><title>Rust and Go</title><url>https://medium.com/@adamhjk/rust-and-go-e18d511fbd95</url></story><parent_chain></parent_chain><comment><author>Animats</author><text>The article is a lightweight analysis by someone who writes small programs.  He does get that, for Rust, &amp;quot;If the compiler accepted my input, it ran — fast and correctly. Period.&amp;quot; That&amp;#x27;s was a common experience with the very tight languages, such as Ada and the various Modulas.  It&amp;#x27;s been a while since a language that tight was mainstream.  We need one now, badly.&lt;p&gt;Go isn&amp;#x27;t bad for writing routine server-side web stuff that has to scale and run fast, which is why Google created it. Go is a modern language with a dated feel.  No user-defined objects, just structs.  No generics or templates. It was designed by old C programmers, and it looks it.  Go has generic objects - maps and channels - and syntax for creating object instances - &amp;quot;Make&amp;quot;.  Only the built-in generics are available, though; you can&amp;#x27;t write new ones.&lt;p&gt;Go&amp;#x27;s &amp;quot;reflection&amp;quot; package thus tends to be overused to work around the lack of generic. This means doing work for each data item at run time for things that could have been done once at compile time.  &amp;quot;interface{}&amp;quot; (Go&amp;#x27;s answer to type Any from Visual Basic) tends to be over-used.&lt;p&gt;Go (especially &amp;quot;Effective Go&amp;quot;) has a lot of hand-waving about parallelism.  Go&amp;#x27;s mantra is &amp;quot;share by communicating, not by sharing&amp;quot;, but all the examples have data shared between threads. The channels are just used as a locking mechanism. Race conditions are possible in Go, and there&amp;#x27;s an exploit which uses this. (That&amp;#x27;s why Google AppEngine limits Go programs to single threads.)
Go doesn&amp;#x27;t use immutability much, which is a lack in a shared-data parallel language with garbage collection. If you can make data immutable, you can safely share it, which is a way to avoid copying without introducing race conditions.&lt;p&gt;Rust, like Erlang, takes a much harder line on enforcing separation and locking.  I haven&amp;#x27;t used Rust myself yet, so I can&amp;#x27;t say more on what it&amp;#x27;s like to use it. My hope is that Rust will provide a solution to buffer overflows in production code. After 35 years of C and its discontents, it&amp;#x27;s time to move on.  I really hope the Rust crowd doesn&amp;#x27;t fuck up.</text></comment>
<story><title>Rust and Go</title><url>https://medium.com/@adamhjk/rust-and-go-e18d511fbd95</url></story><parent_chain></parent_chain><comment><author>freyr</author><text>It&amp;#x27;s not clear how much experience the author really acquired with each language, and whether that experience was sufficient experience to justify his statement:&lt;p&gt;&lt;i&gt;Go felt that way to me — it was good at everything, but nothing grabbed me and made me feel excited in a way I wasn’t already about something else in my ecosystem.&lt;/i&gt;&lt;p&gt;He&amp;#x27;s apparently using each language to write relatively small command-line utilities. If Go is &amp;quot;amazing&amp;quot; at anything, its usually cited as a language of choice for (1) networked systems, and (2) large yet maintainable systems. I&amp;#x27;m not sure his initial foray into the language would have provided enough experience to accurately assess those merits one way or the other.&lt;p&gt;Rob Pike once expressed surprise that people migrating to Go weren&amp;#x27;t C++ programmers, but Ruby&amp;#x2F;Python&amp;#x2F;etc. programmers who needed more performance. That leads you to wonder: (EDIT: removed pejoratives) if a programmer desired to switch from C&amp;#x2F;C++ to another language but hasn&amp;#x27;t by now, why not?&lt;p&gt;1. They require the performance benefits of C&amp;#x2F;C++ (and as humanrebar pointed out, manual memory management).&lt;p&gt;2. They&amp;#x27;re tied to legacy code, with too little incentive to switch.&lt;p&gt;3. They have an organizational mandate.&lt;p&gt;Any programmer who wasn&amp;#x27;t subject to the above constraints and wanted to switch could have done so before Go showed up on the scene. And if a programmer uses C or C++ solely because the above constraints, Go isn&amp;#x27;t likely to change that.&lt;p&gt;Rust may have a better chance of converting C++ programmers, if it offers the performance and control demanded by programmers who are using C++ by necessity. It will be interesting to see if people migrating from Python&amp;#x2F;Ruby to a higher performance language will choose Go or Rust in the future. Kind of like the OP, I like Go but I&amp;#x27;m excited about Rust.</text></comment>