<story><title>The Go Programming Language, or: Why all C-like languages except one suck.</title><url>http://www.syntax-k.de/projekte/go-review</url></story><parent_chain><item><author>andolanra</author><text>Considering only pure language design, I have to say that I&apos;d prefer D to Go. A lot of people who talk about Go use some variation on the phrase &quot;small sets of orthogonal features&quot;—a phrase I feel applies to Go only by comparison with, say, C++—and D doesn&apos;t succeed in that regard, but I feel like D really fits a lot of the points on the wish-list much more closely (e.g. template metaprogramming, data structures, objects, &amp;#38;c. D&apos;s compile-time constructs are incredibly useful without the nastiness of the C preprocessor or C++&apos;s templates.) One thing which draws me to D is the &quot;you can, but you don&apos;t have to&quot; attitude it takes towards certain features—for example, there is GC by default, but you can stop using it and do manual memory management if you feel like it&apos;s important.&lt;p&gt;The problem here, and the massive, massive thing keeping me from throwing my full recommendation behind it, is that D fails entirely on #7, because the community is small and so even installing libraries by hand can be tedious. I keep wanting to pull out D for personal projects, but then I come across some obscure, poorly-documented library with few/no alternatives, and after trying to build it for three hours, I give up and switch to something else. Recently, &apos;something else&apos; has in fact been Go. I still feel like, in an ideal universe, I&apos;d rather program in D than Go, but we do not live in an ideal universe, and of those two, Go is the practical choice. (And, despite my frustrations with Go, it is still better by leaps and bounds than Java and C++.)&lt;p&gt;Also, quick correction: any dynamic language worth its salt does the same short-circut evaluation with &lt;i&gt;and&lt;/i&gt; and &lt;i&gt;or&lt;/i&gt;, including Python, Ruby, Scheme, and Common Lisp, so they all have the property ascribed in this writeup to only JS and Perl. In Python, you can change whether instances of a class are &apos;true&apos; or &apos;false&apos; values by overloading the __nonzero__ method, which means e.g. empty user-defined data structures could be considered &apos;false&apos; while non-empty ones could be &apos;true.&apos; On the other hand, Ruby considers only false and nil to be false values, Scheme considers only #f to be a false value, and Common Lisp considers only nil to be a false value. Aside from individual quibbles about which values are true and false, all of these languages implement an &lt;i&gt;or&lt;/i&gt; that returns the first true value it finds, and all of them implement an &lt;i&gt;and&lt;/i&gt; that returns the first false value it finds.&lt;p&gt;EDIT: Lua also allows the short-circuit boolean operators to return values. The only widely-known dynamic language off the top of my head that doesn&apos;t do this is Smalltalk. This would be complicated to add to a type system, for relatively little gain, so as far as I know, no typed language allows it.</text></item></parent_chain><comment><author>rsaarelm</author><text>Especially with Andrei Alexandrescu on board, D is striving for some very interesting stuff with its template metaprogramming system. I think Alexandrescu said in an interview somewhere that the goal is to have a language where you don&apos;t ever need to reimplement an algorithm once you&apos;ve gotten it right once in a library.&lt;p&gt;This gets particularly interesting with mathematical code. If you have a templatized math function like a linear interpolation function, you can swap in integers, reals or complex numbers without writing new code, and also matrices, vectors or quaternions from another library, provided that they have the algebraic properties the function expects. Go is nowhere near allowing this degree of write-the-algorithm-only-once, as it both lacks generic types and has numeric types as privileged constructs you can&apos;t substitute with user-defined ones.</text></comment>
<story><title>The Go Programming Language, or: Why all C-like languages except one suck.</title><url>http://www.syntax-k.de/projekte/go-review</url></story><parent_chain><item><author>andolanra</author><text>Considering only pure language design, I have to say that I&apos;d prefer D to Go. A lot of people who talk about Go use some variation on the phrase &quot;small sets of orthogonal features&quot;—a phrase I feel applies to Go only by comparison with, say, C++—and D doesn&apos;t succeed in that regard, but I feel like D really fits a lot of the points on the wish-list much more closely (e.g. template metaprogramming, data structures, objects, &amp;#38;c. D&apos;s compile-time constructs are incredibly useful without the nastiness of the C preprocessor or C++&apos;s templates.) One thing which draws me to D is the &quot;you can, but you don&apos;t have to&quot; attitude it takes towards certain features—for example, there is GC by default, but you can stop using it and do manual memory management if you feel like it&apos;s important.&lt;p&gt;The problem here, and the massive, massive thing keeping me from throwing my full recommendation behind it, is that D fails entirely on #7, because the community is small and so even installing libraries by hand can be tedious. I keep wanting to pull out D for personal projects, but then I come across some obscure, poorly-documented library with few/no alternatives, and after trying to build it for three hours, I give up and switch to something else. Recently, &apos;something else&apos; has in fact been Go. I still feel like, in an ideal universe, I&apos;d rather program in D than Go, but we do not live in an ideal universe, and of those two, Go is the practical choice. (And, despite my frustrations with Go, it is still better by leaps and bounds than Java and C++.)&lt;p&gt;Also, quick correction: any dynamic language worth its salt does the same short-circut evaluation with &lt;i&gt;and&lt;/i&gt; and &lt;i&gt;or&lt;/i&gt;, including Python, Ruby, Scheme, and Common Lisp, so they all have the property ascribed in this writeup to only JS and Perl. In Python, you can change whether instances of a class are &apos;true&apos; or &apos;false&apos; values by overloading the __nonzero__ method, which means e.g. empty user-defined data structures could be considered &apos;false&apos; while non-empty ones could be &apos;true.&apos; On the other hand, Ruby considers only false and nil to be false values, Scheme considers only #f to be a false value, and Common Lisp considers only nil to be a false value. Aside from individual quibbles about which values are true and false, all of these languages implement an &lt;i&gt;or&lt;/i&gt; that returns the first true value it finds, and all of them implement an &lt;i&gt;and&lt;/i&gt; that returns the first false value it finds.&lt;p&gt;EDIT: Lua also allows the short-circuit boolean operators to return values. The only widely-known dynamic language off the top of my head that doesn&apos;t do this is Smalltalk. This would be complicated to add to a type system, for relatively little gain, so as far as I know, no typed language allows it.</text></item></parent_chain><comment><author>firemanx</author><text>I was thinking along those lines as well, though the first language that came to my head was actually c# (my second thought was D).  It may not be listed due to it&apos;s precarious position in the world, but it answers the majority of the points on his list, though still runs in a vm environment.  Perhaps that&apos;s the distinction.&lt;p&gt;An aside - using implicit typing in c# you can have an object perform as a boolean in boolean expressions.  You can also use implicit typing for more than just booleans as well.</text></comment>