Why Go? Use Racket

I&#x27;m sorry you lost me after your outrageous claim that one must learn everything about the standard types of Go before one can program effectively.<p>You should know about how your types are passed around if you are using any language.<p>The example given was arrays in Go. Arrays are passed by value, but slices (pointers to arrays) are passed by reference. This is very simply described in the Effective Go reading. It&#x27;s not a hard concept. I don&#x27;t like you writing off Go with that example. It sounds like you made an emotional decision against the language and are grasping for logical reasons to support your already made decision.<p>How many people programming with Go pass arrays around? It&#x27;s an easy lesson to learn.

No. Because static typing.<p>However much Go&#x27;s type system might lack some means of expression, the type system is there, and it prevents many bugs that can easily crop up while using a dynamic language.<p>I&#x27;d rather say &#x27;use OCaml&#x27; or &#x27;use F#&#x27; or even &#x27;use Haskell&#x27;.

The OP&#x27;s complaint about Go&#x27;s type system seems to mainly be that memory allocation is explicit.<p>Go is always &quot;pass by value&quot;, and it&#x27;s true that I&#x27;ve watched developers struggle to grasp the full ramifications of what that means regarding memory usage. But not understanding the subtlety of memory allocation usually means your programs will simply run slower and consume more memory. It does not usually mean that your programs will run incorrectly.<p>Given that the OP mentions that they find the slower, more expensive execution of racket programs to be an acceptable trade-off, I&#x27;m surprised that they have a problem with this.<p>Personally, I prefer running in a language that allows me to reason about the memory allocation explicitly. I&#x27;d only prefer to give that up in favor of a declarative language that could compute the optimal execution for me. Unfortunately that language is a bit of a unicorn for general purpose programming.

Of the complaints you can make about Go&#x27;s type system (and there are many), being too complex is not one of them.

In the comments he says he changed his mind about Go, and the necessity of the efficiency gain over Racket. So there&#x27;s some confusion apparently. <a href="https://cxwangyi.wordpress.com/2012/07/22/why-go-use-racket/#comment-871" rel="nofollow">https:&#x2F;&#x2F;cxwangyi.wordpress.com&#x2F;2012&#x2F;07&#x2F;22&#x2F;why-go-use-racket&#x2F;...</a>

It&#x27;s a chicken and egg problem, but the real reason for me to use Go vs Racket is that learning the former will further my career significantly, while latter won&#x27;t at all. Sad, but true.

Author thinks Go&#x27;s select statement has any resemblance to with epoll and kqueue. Didn&#x27;t read further.

I like crosscompilation and being able to deploy a stand alone executable without the whole sdk needed.Does racket do that?

The blog post is a couple of years old, so it&#x27;s probably worth noting that <i>PLaneT</i>[1], mentioned by the author, has been superseded by a new <i>Packages</i>[2] system. PLaneT is still operating, however, and libraries hosted there can be installed with raco[3].<p>[1] <a href="http://planet.racket-lang.org/" rel="nofollow">http:&#x2F;&#x2F;planet.racket-lang.org&#x2F;</a><p>[2] <a href="http://pkgs.racket-lang.org/" rel="nofollow">http:&#x2F;&#x2F;pkgs.racket-lang.org&#x2F;</a><p>[3] <a href="http://docs.racket-lang.org/raco/index.html?q=" rel="nofollow">http:&#x2F;&#x2F;docs.racket-lang.org&#x2F;raco&#x2F;index.html?q=</a>

I&#x27;ll come right out and say that I <i>despise</i> Go. It&#x27;s a terrible language that ignores decades of language research and brings nothing new to the field, but has become popular due to Google hype.<p>That said, Go -&gt; Racket is a pretty big jump. Even though I think Go is terrible, I can at least take the time to see the problems it&#x27;s solving and offer comparable languages. I suggest Rust as a Go replacement.<p>Don&#x27;t get me wrong, Racket is pretty good. It&#x27;s not the Lisp I would pick (I really like Gambit Scheme) but it&#x27;s at least a Lisp. But a high-level language like Racket isn&#x27;t really comparable to Go. They&#x27;re just in different spaces.

I&#x27;m inclined to disagree about the distinction between pointers and values being explicit, and how that is bad - I think it might be the right decision in an imperative language that tries to be performant in a straightforward way (as opposed to language that tries to be performant by relying on compiler optimizations - that might work for certain languages). It allows you to be aware and more careful about indirection and memory layout, which obviously can buy you a lot with regards to performance.<p>It certainly seems like the more lower-hanging fruit than what the usual advice for getting a fast programming language is - make memory management explicit&#x2F;manual (though it seems that if you have pervasive manual memory management, you end up with a clear and explicit distinction between values and pointers to values anyway).

shouldn&#x27;t be: Why Go? (Use (Racket))

Racket&#x27;s website (<a href="http://racket-lang.org/" rel="nofollow">http:&#x2F;&#x2F;racket-lang.org&#x2F;</a>) has an &quot;explain&quot; button by the code snippet. Is the existence of such a button perhaps a statement about the quality of the syntax?