<p>If Haskell is hard to learn, and Go is much easier to learn, especially for programmers experienced with C, C++, Java, Python, etc., is that alone a good enough reason to prefer Go over Haskell? Or are there other, better, reasons to take into account, when making such decisions?</p>
<hr/>**评论：**<br/><br/>Shonucic: <pre><p>This is sort of like asking, "Since apples can be eaten with the skin on, and pomegranate are hard to peel, is that alone a good enough reason to always eat apples."</p></pre>y216567629137: <pre><p>The question is predicated on choosing one or the other. It's not a question of whether you should choose one, but, rather, which you would choose if you were choosing one. Apples vs pomegranates is not a good analogy, because you can make different choices different days. But when you organize a software development project, you don't choose a different programming language every day.</p></pre>goomba_gibbon: <pre><p>Apples vs. penguins might be a better analogy. I'm sure most people will agree that Go is significantly easier to learn but it's impossible to say which one you'll prefer without knowing more about what you want to achieve.</p>
<p>Want to learn a language quickly? Looking for a job? Want to learn functional programming? Any projects in mind? Will you need 3rd party libs for anything specific?</p></pre>TheMerovius: <pre><blockquote>
<p>which you would choose if you were choosing one.</p>
</blockquote>
<p>I think this is the wrong forum for this question. It will be hugely biased towards go.</p></pre>bmurphy1976: <pre><p>False dichotomy.</p>
<p>There's no context here. Context is important. Depending on your context, you may prefer one or the other. What's the context?</p>
<ol>
<li>Are you learning something new?</li>
<li>Are you developing an application from scratch?</li>
<li>Are you maintaining an existing application?</li>
<li>Do you you have requirements driven by users?</li>
<li>Do you have requirements driven by developers?</li>
<li>Do you have financial constraints?</li>
<li>Are peoples lives at risk if you make mistakes?</li>
<li>What's the scope of the project?</li>
<li>What's the size of your organization?</li>
<li>How difficult/important is it to onboard new programmers? </li>
<li>etc..</li>
<li>etc..</li>
<li>etc..</li>
</ol>
<p>Without answers to those questions, nobody can tell you if you should prefer one or the other. And who knows, you might actually use both!! We have an application that is a Go backend with an Elm (Haskell-Light) frontend.</p></pre>sin2pifx: <pre><blockquote>
<p>False dichotomy.</p>
</blockquote>
<p>Not the correct term. The limitation is part of the question. OP knows there are more languages. But most of your points are relevant: context is important for answering the question.</p></pre>y216567629137: <pre><p>To say it's a false dichotomy is to say they aren't really different answers to the same problems. But, for a typical software development project, you do have to choose a programming language, and can't keep changing your choice as your needs evolve. A software development organization gains expertise in a set of technologies, and needs to be able to apply the same technologies to related problems. The old argument that when you only have a hammer, everything looks like a nail, is actually closer to reality than it seems, in more ways than one. A typical software development organization can't work efficiently and effectively with an excessively large tool set. They have to optimize their choice of tools for a wide range of problems.</p>
<p>One advantage of Haskell is that if you hire programmers and train them to use Haskell, they can't easily leave your organization to get other Haskell jobs elsewhere. But that could also be construed as a disadvantage.</p>
<p>My question was what the advantages of Go were, not whether those advantages would be applicable in a particular context.</p>
<p>And it's not really a question of which you should choose, but a question of what the reasons might be for choosing one over the other.</p></pre>very-little-gravitas: <pre><blockquote>
<p>if you hire programmers and train them to use Haskell, they can't easily leave </p>
</blockquote>
<p>I certainly wouldn't use this criteria to choose. </p>
<blockquote>
<p>And it's not really a question of which you should choose, but a question of what the reasons might be for choosing one over the other.</p>
</blockquote>
<p>Here are some reasons why you might choose one or the other (mostly cultural/subjective):</p>
<p>Do you like abstraction and purity? Do you like clever or very dense code? Do you like functional programming? Choose Haskell.</p>
<p>Do you value pragmatism over purity? Do you like simple code (even if verbose)? Have you come to dislike clever code? Do you like imperative programming? Choose Go.</p></pre>unimpaired: <pre><p><a href="https://blog.pusher.com/golangs-real-time-gc-in-theory-and-practice/" rel="nofollow">Here</a> is a write up about Pusher moving one of their services from Haskell to Go that does a decent job of highlighting what they found to be benefits. Most of it seems centered around GC performance.</p></pre>comrade_donkey: <pre><p>The full answer would be very long and it's arguably hard to write without some bias in one way or the other. If I had to mention some key points I'd say this: Go is an imperative language, whereas Haskell is declarative. This and Go's memory-near expressivity makes it more machine-oriented, giving you a near-metal experience, while still being easy and concise. Haskell is the master of abstraction and reading/writing Haskell is not nearly as easy. However, the abstractions Haskell offers, like a mega powerful type-system, give you a different kind of expressivity, a more "mathematical" one. In the end, it depends on you, what you like and what your team likes, and what your common goal is.</p></pre>pinpinbo: <pre><p>Beyond personal learning, it also depends on your office environment:</p>
<ul>
<li><p>What is the likelihood that you can teach your coworkers Haskell vs Go?</p></li>
<li><p>What is the likelihood that your coworkers be willing to pickup Haskell/Go themselves?</p></li>
<li><p>Which one do you think is easier to get approved by your boss?</p></li>
<li><p>Which one is easier to integrate to the existing CI pipeline?</p></li>
<li><p>Which one is easier for your SRE team to deploy?</p></li>
<li><p>Which one is easier to write tests and debug?</p></li>
<li><p>etc.</p></li>
</ul></pre>metakeule: <pre><p>I think the main advantage, Go has over Haskell is that Go code is easier to understand and to follow (both in terms of what it should do and what is actually done). That makes Go code easier to refactor and maintain. Go has much less compiler magic and allows much less programmer's magic via abstractions which translates to less mental overhead when trying to understand code.</p></pre>y216567629137: <pre><p>For example, is the Haskell code below hard to understand and follow? It's a quicksort that sorts a string, e.g.</p>
<pre><code>"This string has 4 spaces"
</code></pre>
<p>becomes</p>
<pre><code>" 4Taaceghhiinprssssst"
</code></pre>
<p>What would this code look like in Go?</p>
<pre><code>qs :: String -> String
qs [] = []
qs s = let x = head s
y = tail s
a = qs (filter (<=x) y)
b = qs (filter (>x) y)
in a ++ [x] ++ b
</code></pre></pre>edapa: <pre><p>That not quicksort. Quicksort is explicitly an algorithm that mutates arrays. This actually illustrates the difference between go and Haskell pretty well. It may take you 2 lines of haskell to write</p>
<pre><code>qs [] = []
qs (x:xs) = (filter (<=x) xs) ++ (x : (filter (>x) xs)))
</code></pre>
<p>but that does not run in O(nlogn) time, which is fairly important. In go your implementation would probably be 20 times as long and take much longer to write (assuming equal proficiency in both languages), but it would be hard to make a mistake about the running time. Haskell is really good at abstraction, sometimes to its own detriment.</p></pre>y216567629137: <pre><p>Here is yours with some minor bugs fixed:</p>
<pre><code>qs [] = []
qs (x:xs) = (qs (filter (<=x) xs)) ++ (x : (qs (filter (>x) xs)))
</code></pre>
<p>Mine was arbitrarily restricted to Strings, but yours works equally with Strings. It would be interesting for someone who has both Haskell and Go installed on their computer to try both with big strings to see how slow the Haskell really is. An easy way to generate a big String in Haskell is:</p>
<pre><code>bigstring e = show (2^(2^e))
</code></pre>
<p>and give it a number such as 15 or 20 depending on how big you want the string to be.</p>
<p>Then, instead of displaying the whole result, just display part of it, with take n, or its length or something, to not spend time watching your monitor output a lot of text. E.g.</p>
<pre><code>GHCi> length (qs (bigstring 15))
9865
(1.61 secs, 704,357,672 bytes)
GHCi>
</code></pre>
<p>The above is interpreted Haskell. Compiling the functions changes the 1.61 seconds to 0.61 seconds on my computer.</p></pre>Akkifokkusu: <pre><p>The Go equivalent looks something like</p>
<pre><code>func qs(s string) string {
if s == "" {
return ""
}
x, size := utf8.DecodeRuneInString(s)
y := s[size:]
a := strings.Map(func(r rune) rune {
if r <= x {
return r
}
return -1
}, y)
b := strings.Map(func(r rune) rune {
if r > x {
return r
}
return -1
}, y)
return qs(a) + string(x) + qs(b)
}
</code></pre>
<p>As someone used to imperative languages, the Haskell version took me some time to understand. The <code>rune</code> bits in the Go version may be hard to understand for those not familiar with how strings work in Go.</p>
<p>Edit: cleaned up <code>x</code> and <code>y</code> a little.</p></pre>metakeule: <pre><p>don't think that quicksort is a good example, but anyway:
<a href="https://gist.github.com/vderyagin/4161347" rel="nofollow">https://gist.github.com/vderyagin/4161347</a></p>
<p>I think Go is easier to follow in terms of code organization and known idioms. (e.g. monads are not that easy to graps)</p></pre>very-little-gravitas: <pre><p>You want to sort the characters in a string in Go?</p>
<pre><code>s := strings.Split("This string has 4 spaces", "")
sort.Strings(s)
str := strings.Join(s, "")
</code></pre>
<p><a href="https://play.golang.org/p/pb96awRKU9" rel="nofollow">https://play.golang.org/p/pb96awRKU9</a></p>
<p>Presumably you don't want to rewrite quicksort every time? If you did a real quicksort in haskell it might also be long:</p>
<p><a href="http://stackoverflow.com/questions/7717691/why-is-the-minimalist-example-haskell-quicksort-not-a-true-quicksort#7718269" rel="nofollow">http://stackoverflow.com/questions/7717691/why-is-the-minimalist-example-haskell-quicksort-not-a-true-quicksort#7718269</a></p></pre>y216567629137: <pre><p>The point is to compare code, and possibly time the code. It doesn't matter if it's a sort or what. Just anything that can be used as an example, to compare the languages, to understand their advantages and disadvantages.</p></pre>very-little-gravitas: <pre><p>Is performance a huge concern? If so this microbenchmark would tell you very little and I don't think would be a useful comparison of languages. </p></pre>y216567629137: <pre><p>The issue is whether performance is a big issue. In other words, is there a big difference in performance, that would be a major concern for most types of software development? Or is it more like a few percent slower in some situations? A performance difference most people could safely ignore? Or a big difference they should take into account?</p></pre>tmornini: <pre><p>Simplicity.</p></pre>cube2222: <pre><p>First of all, because of Haskell's laziness performance is often unpredictable -> at the same time you can tune Go to be as fast as it realistically can be.</p>
<p>You'll have a hard time finding programmers for Haskell. It's not a good idea to say "we'll teach em Haskell) because the whole paradigm and theoretical fundamentals take a while to learn.</p>
<p>You'll also have to write most libraries yourself, in Go you have libraries to most projects you would need.</p>
<p>All in all, I think that if you have to ask, then you should really use Go. Definitely not Haskell. If you want to go down the FP path then maybe Scala?</p></pre>
