<p>In 2004 Tim Peters distilled the Philosophy of Python into 20 axioms/aphorisms (only 19 of which were written down). When I read them for the first time I remember feeling a kinship with Python that I had never felt when working with C, C++, C#, VB, or Java. Something about them projected of the way Python programers thought. The quirkiness, tone, and cadence still leaves me grinning. </p>
<p>If you've never read Zen of Python I recommend you open up python repl and type "import this" or <a href="https://www.python.org/dev/peps/pep-0020/">https://www.python.org/dev/peps/pep-0020/</a>.</p>
<p>Consider the philosophy of Go, its creators, and ecosystem for a minute. What is would you submit as the Zen of Go?</p>
<hr/>**评论：**<br/><br/>pinpinbo: <pre><ol>
<li>Get shits done in a fast, readable, testable, predictable manner.</li>
<li>That's all.</li>
</ol></pre>Husio: <pre><blockquote>
<p>Get shits done in a fast, readable, testable, predictable manner.</p>
</blockquote>
<p>I had to try my luck with <a href="http://www.languageisavirus.com/interactive-haiku-generator.html?ac=Generate" rel="nofollow">http://www.languageisavirus.com/interactive-haiku-generator.html?ac=Generate</a></p>
<pre><code>shits
As readable who Get readable
And predictable.
</code></pre></pre>kemist: <pre><p>Short and sweet :)</p></pre>cs-guy: <pre><p><a href="http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html">Less is exponentially more.</a></p></pre>kemist: <pre><p>In the spirit of Python's Zen...</p>
<p>Less is exponentially more
Unless you're doing math, then less is less</p></pre>Streamweaver66: <pre><p>It seems like Go was designed with at least a lot of the core concepts of the Zen of Python in mind</p>
<p>I think python gave birth to a community of thinking that extended beyond the language that shaped Go weather we admit it or not.</p></pre>chickenphobia: <pre><p>I submit: the sarcastic zen if go.</p>
<p>1) There should be only one way of doing anything, unless that thing is a go built-in function.</p>
<p>2) renaming is better than overloading anyways*.</p>
<p>3) Nobody needs a number type that's not already built-in**.</p>
<p>4) Always maintain go's type safety, unless you are a library developer, then just use the unsafe package to hack around it.</p>
<p>*caveat for #2, see #1</p>
<p>** My toilet paper is made of IEEE 854.</p></pre>aboukirev: <pre><p>5) Idiomatic is better than elegant. ;)</p></pre>chickenphobia: <pre><p>6) Every problem can (and should) be solved using goroutines.</p></pre>SupersonicSpitfire: <pre><ol>
<li>We don't sugar your cake.</li>
<li>There is no cake.</li>
<li>The color of the bikeshed has already been selected.</li>
<li>But you can use several bikes at once, concurrently.</li>
<li>There shall be no arguments about syntax or formatting.</li>
<li>But there may be endless arguments about generics.</li>
<li>All Go code is readable by all Go programmers.</li>
<li>Teams matter, individual programmers does not.</li>
<li>But we like your github projects, keep sharing them please.</li>
<li>Only slightly autistic gophers are suitable for logos and profile images.</li>
</ol></pre>flambasted: <pre><pre><code>select{}
</code></pre></pre>scapbi: <pre><p>Go and the Zen of Python
<a href="https://talks.golang.org/2012/zen.slide#1">https://talks.golang.org/2012/zen.slide#1</a></p></pre>natefinch: <pre><p>The zen of python is quite similar to what I would write as the zen of go. Go is just much better at following it.</p></pre>boarhog: <pre><p>Why would you say Go is better at following it?</p></pre>natefinch: <pre><p>Selected axioms:</p>
<pre><code>Explicit is better than implicit.
</code></pre>
<p>Go requires all type conversion to be explicit. Go has static typing. Python lets a lot of crap code slide, without the programmer needing to be explicit, like assigning a value to a name that didn't exist before or converting random things to booleans.</p>
<pre><code>Simple is better than complex.
Complex is better than complicated.
</code></pre>
<p>There's a lot of magic in python... anything with __ is effectively magic. You can write python code that does really bizarre things from normal-looking code. This is useful for writing DSLs, but makes it very easy to write incredibly complex code that can have very surprising behavior. Just writing a + b could potentially go download files from the network, for example.</p>
<p>The thing I like about go code is that it is very very obvious what any one particular line is doing, often right down to what memory is getting copied or created. </p>
<pre><code>Sparse is better than dense.
Readability counts.
</code></pre>
<p>List comprehensions anyone? Mashing a whole loop into a single line does not really seem like it fits either of these axioms.</p>
<pre><code>Errors should never pass silently.
Unless explicitly silenced.
</code></pre>
<p>I think Go goes one step further and states that potential failure should always be obvious. Even the most basic python code can throw an exception. You just never know where it can fail. Go requires that if a function can fail, it must have an error return type. That's a lot "louder" to me than exception.. sure exceptions can't be ignored at runtime without explicitly catching them, but they can certainly easily be ignored at code-writing time, which seems worse to me. It seems to fit in with the general theme of dynamic typing vs. static typing. I want to be told when I compile that I'm not handling an error, not wait until runtime to have my program explode.</p>
<pre><code>Namespaces are one honking great idea -- let's do more of those!
</code></pre>
<p>I think go's packages work better than python's modules. It's far too common to see <em>from foo import bar</em> and then you can use bar like it's in the local namespace. I much prefer go's unavoidable namespaces that force you to type foo.bar every time.</p></pre>dgryski: <pre><p>Also interesting: <a href="https://talks.golang.org/2012/zen.slide">https://talks.golang.org/2012/zen.slide</a></p></pre>nosmileface: <pre><p>To me, Go just adheres more fundamental philosophical ideas: KISS, YAGNI, DRY. Few examples:</p>
<ol>
<li>It keeps things simple with orthogonal features. Implicit interfaces, types and method sets, functions and goroutines.</li>
<li>You ain't gonna need generics for most of your work, but Go stays practical and provides common generic types (arrays, maps, channels) and functions. Not to mention other popular language features that are absent in Go: inheritance, function overloading, operator overloading, const type modifier, exceptions as part of API, etc.</li>
<li>DRY: <code>func lerp(a, b, v float32) float32</code> and type inference of course. Go's iota for const definitions. Very lightweight syntax in general.</li>
</ol>
<p>Knowing these principles, you also need to learn to avoid extremes. For example the fact that Go always asks for explicit receiver when defining methods may seem like a violation of DRY. But at the same time it keeps things simple by eliminating ugly nesting (which is a bad idea in textual representation).</p></pre>djhworld: <pre><blockquote>
<p>DRY</p>
</blockquote>
<p>While this is true in some respects, you could argue that the lack of generics violates this principle <em>in some cases</em> </p></pre>jerf: <pre><p>When KISS and DRY conflict, Go prefers KISS.</p>
<p>I'm not advocating for that, just observing it. I'm still not sure I agree personally, but it hasn't been a fatal problem.</p></pre>nosmileface: <pre><p>Yes, I agree. I would like to see generics in Go, but I like the language either way.</p></pre>koffiezet: <pre><p>As mentioned here, quite similar to the zen of python.</p>
<p>I'd also add: everything is a library.</p></pre>gureggu: <pre><p><a href="http://golang.org/pkg/net/http/#HandlerFunc" rel="nofollow">http.HandlerFunc</a></p></pre>
