<p>What comes to mind when considering 'simplicity and Go'?</p>
<p>In particular:</p>
<ul>
<li>What is simple in Go the language and the platform.</li>
<li>What isn't simple in Go</li>
<li>Making your Go programs simple.</li>
</ul>
<p>Feel free to illustrate with samples or using the go playground</p>
<p><em>Note: I'm crowdsourcing for a presentation on Simplicity and Go. I've written a bunch of content and prepared a few code samples, but I'd like to hear what you think.</em></p>
<p>Thanks</p>
<hr/>**评论：**<br/><br/>shovelpost: <pre><p>I will just leave <a href="https://www.youtube.com/watch?v=rFejpH_tAHM">this</a> here.</p></pre>R2A2: <pre><p>Thanks, that talk pretty much inspired my presentation. Rob suggests that Go's success is due to simplicity. He says simplicity is multi-faceted, and that although Go has complexity, it should <em>feel</em> simple to use.</p>
<p>So I'm wondering how people feel about that. Does it feel simple, in what way, and which parts don't feel simple?</p></pre>fungussa: <pre><ul>
<li><p>Concurrency is a first-class language feature.</p></li>
<li><p>Duck-typing - one doesn't need to explicitly define class hierarchies, as interfaces are implicitly satisfied.</p></li>
<li><p>Reduced language keyword set, and eg there's only one loop construct (for).</p></li>
<li><p>Garbage collection.</p></li>
<li><p>First-class built-in tooling: race detection, profiling, tracing, etc.</p></li>
<li><p>Symbols are accessible outside of a package simply by the type / value having a name with a capitalised first letter.</p></li>
<li><p>No project files!</p></li>
<li><p>Cross-compiling available on all platforms on which the language is supported. ie on Linux I can easily compile for Arm, Windows, etc.</p></li>
<li><p>Built-in documentation generation.</p></li>
<li><p>Compilation generates single target files, reducing dependencies.</p></li>
<li><p>The language is bordering on being sealed, meaning code which compiled today will still compile years from now.</p></li>
<li><p>The language favours composition over inheritance, reducing complexity.</p></li>
</ul></pre>bobbafeftta: <pre><blockquote>
<p>No project files!</p>
</blockquote>
<p>I absolutely love this about go</p></pre>usernameliteral: <pre><blockquote>
<p>Duck-typing - one doesn't need to explicitly define class hierarchies, as interfaces are implicitly satisfied.</p>
</blockquote>
<p>It's actually <a href="https://en.wikipedia.org/wiki/Structural_type_system">structural typing</a>, not duck typing.</p></pre>meggawatts: <pre><blockquote>
<p>Cross-compiling available on all platforms</p>
</blockquote>
<p>One of my personal favorites!</p></pre>R2A2: <pre><p>Great answer, thanks</p></pre>MalkMalice: <pre><p>One of the first things which comes to my mind when thinking about simplicity and Go is the amount of keywords of the language: <a href="https://golang.org/ref/spec#Keywords">https://golang.org/ref/spec#Keywords</a></p></pre>statistmonad: <pre><p>You may be interested to know that Haskell has less keywords than Go so I don't know if that is a great indicator of "simplicity".</p></pre>ChristophBerger: <pre><p>A small amount of keywords does not necessarily indicate a simple language, but a large amount of keywords certainly indicates a complex language.</p>
<p>So a small number of keywords is required but not sufficient for designing a language that is simple to use.</p></pre>bobbafeftta: <pre><p>it is worth noting that go has additional <del>"keywords"</del> built-in functions that are not reserved, such as</p>
<pre><code>len
new
delete
append
make
</code></pre>
<p>*Edit: Thanks <a href="/u/ChristophBerger">/u/ChristophBerger</a> for the correction</p></pre>ChristophBerger: <pre><p><code>len</code>is a built-in function, not a language keyword in the strict meaning of the word. But I agree that <code>len</code>, <code>new</code>, <code>delete</code>, <code>append</code>, and other built-in functions should be treated similar to the reserved keywords and at least be mentioned alongside of those.</p></pre>R2A2: <pre><p>That seems like a good indicator of the language's size. As does the small spec itself.</p>
<p>Anything else? What's not so simple?</p></pre>jerf: <pre><p>For all that Go by <em>convention</em> uses relatively safe concurrency abstractions, you are, technically, still using old-school threading, and that can get complicated. I find it easy to either A: use channels or B: use a single lock at a time (locks only get complicated if you have a need to take more than one), but it's still pretty easy for me to accidentally overshare a field somewhere. Most recently I got bitten because the gocql library has a method <code>func (q *Query) Bind(vals ...interface{}) *Query</code> and I thought from the type signature that it was returning a <em>new</em> Query. Whoops. Nope. It's for chaining.</p>
<p>The simplicity of the language means that you take a hit in the code. In the worst case, you're duplicating code to be "generic", but there are other places where you're going to be writing several lines of code to do something that other languages can do much more quickly. Though, that said, I find that egregious code expansion happens less often than critics claim, most of whom have never used the language, and most of the rest of whom used it in some way I would recommend against. (Specifically, high-performance mathematical code, where you want to write things generic to int64/int32/uint32/float64, and matrices of difference sizes, etc.)</p>
<p>I'd also defend that a bit by pointing out that the simpler code ends up being more broadly understandable. More programmers understand</p>
<pre><code>newArray := []int{}
for i := 0; i < len(arr); i++ {
if arr[i] > threshold {
newArray = append(newArray, arr[i])
}
}
</code></pre>
<p>than understand</p>
<pre><code>newArray := [elem for elem in arr if elem > threshold]
</code></pre>
<p>And while as someone who does understand the latter, it does sometimes hurt to have to write the former, I've also learned that it is often <em>more professional</em> to use the former in a context where the code may end up in anybody's hands.</p></pre>theclapp: <pre><p>If you’re an experienced programmer, the spec is pretty short and approachable and easy to read. I frequently use it directly to answer language questions (instead of, say, StackOverflow et al).</p></pre>cIIsco_: <pre><p>How well documented every package of the stdlib is, as well as community libraries. GO just has an excellent community in general and this can prove helpful for anyone new to the language. </p></pre>: <pre><p>[deleted]</p></pre>cIIsco_: <pre><p>You are completely correct in saying that, but I am also referring to how the community helps out</p></pre>
