<story><title>Go Bloviations</title><url>http://ridiculousfish.com/blog/posts/go_bloviations.html</url></story><parent_chain><item><author>cletus</author><text>A couple of responses:&lt;p&gt;- I too dislike the lack of a ternary operator. Python has this problem too (you can create boolean expressions to sorta mimic it but it doesn&apos;t tend to be considered &quot;Pythonic&quot;). And brevity is my reason too. I&apos;m sure it&apos;s easier to parse without it but it can&apos;t be that hard.&lt;p&gt;- On the &quot;damnable use requirement&quot;, I see his point. If anything, it means that Go will be better used with IDEs than text editors that&apos;ll do this for you automatically;&lt;p&gt;- On the &quot;thread safe set&quot;, yeah he&apos;s Doing It Wrong [tm] (which I think he knows). You use channels to share state in Go rather than creating shared state directly.&lt;p&gt;- Unbuffered channels seem to be idomatic. Race conditions and deadlocks seem to often be the result of using buffered channels;&lt;p&gt;- On his channel reads issue (&quot;violating time and space&quot;) I disagree: it&apos;s good to have blocking and non-blocking channel reads.&lt;p&gt;I basically agree with his conclusions, particularly in Go feeling like a &quot;modern C&quot;, something I desperately hope succeeds.</text></item></parent_chain><comment><author>Jabbles</author><text>Go doesn&apos;t have non-blocking receives anymore.&lt;p&gt;&lt;pre&gt;&lt;code&gt;  value, ok := &amp;#60;- ch
&lt;/code&gt;&lt;/pre&gt;
will block, always. Iff the channel is closed, ok will be false, allowing you to distinguish between a zero value sent on the channel, and the zero value you get back if you try to receive on a closed channel. Receiving from a nil channel always blocks.&lt;p&gt;Select statements allow you to check if a channel has had a value sent on it.&lt;p&gt;&lt;a href=&quot;http://golang.org/ref/spec#Receive_operator&quot; rel=&quot;nofollow&quot;&gt;http://golang.org/ref/spec#Receive_operator&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;https://groups.google.com/d/msg/golang-nuts/Z63l4LDOlsI/54uTd4x9eiIJ&quot; rel=&quot;nofollow&quot;&gt;https://groups.google.com/d/msg/golang-nuts/Z63l4LDOlsI/54uT...&lt;/a&gt;&lt;p&gt;&lt;a href=&quot;http://golang.org/ref/spec#Select_statements&quot; rel=&quot;nofollow&quot;&gt;http://golang.org/ref/spec#Select_statements&lt;/a&gt;</text></comment>
<story><title>Go Bloviations</title><url>http://ridiculousfish.com/blog/posts/go_bloviations.html</url></story><parent_chain><item><author>cletus</author><text>A couple of responses:&lt;p&gt;- I too dislike the lack of a ternary operator. Python has this problem too (you can create boolean expressions to sorta mimic it but it doesn&apos;t tend to be considered &quot;Pythonic&quot;). And brevity is my reason too. I&apos;m sure it&apos;s easier to parse without it but it can&apos;t be that hard.&lt;p&gt;- On the &quot;damnable use requirement&quot;, I see his point. If anything, it means that Go will be better used with IDEs than text editors that&apos;ll do this for you automatically;&lt;p&gt;- On the &quot;thread safe set&quot;, yeah he&apos;s Doing It Wrong [tm] (which I think he knows). You use channels to share state in Go rather than creating shared state directly.&lt;p&gt;- Unbuffered channels seem to be idomatic. Race conditions and deadlocks seem to often be the result of using buffered channels;&lt;p&gt;- On his channel reads issue (&quot;violating time and space&quot;) I disagree: it&apos;s good to have blocking and non-blocking channel reads.&lt;p&gt;I basically agree with his conclusions, particularly in Go feeling like a &quot;modern C&quot;, something I desperately hope succeeds.</text></item></parent_chain><comment><author>psykotic</author><text>&amp;#62; Python has this problem too&lt;p&gt;Python has had conditional expressions since version 2.5. Dumb example:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    def count(xs, p):
        return sum(1 if p(x) else 0 for x in xs)&lt;/code&gt;&lt;/pre&gt;</text></comment>