What articles are you talking about? This couldn't be further from the truth. Go is a practical language meant to be used in production settings. It's not a haskell. For example, it's support for protocol buffers is second to none imo.
Well, it wasn't. Haskell was designed primarily as a test bed for writing language features to support PhD theses. The great success of Haskell is the amount of new language ideas it generated, which we now see in many other places.
Being a real-world language was absolutely one of the design goals of Haskell. See point 1 of section 2.4 in "A History of Haskell: Being Lazy With Class"[1]. It succeeded at being suitable for writing large systems, too. It's easily the least-bad language I've used for writing software where garbage collection is acceptable. It hits a sweet spot between expressiveness, maintainability, and performance that I haven't experienced from any other language.
Question: Have you used Haskell to write real software? I find that people who have used it tend to have much more precise criticism than "isn't designed for writing real software". It certainly has lots to criticize, just like every other language. But most of the criticisms I see of it seem to have gone through 20 rounds of telephone, with basically no relation to the reality of using Haskell.
The title: "Go at Google: Language Design in the Service of Software Engineering"
It puts building production software as the first most important goal.
It then goes in depth about how design decisions were driven by things the authors learned from Google's vast experience of writing production software.
It methodically describes pain points of large-scale software production and how Go's design decisions are trying to address those pain points.
Unlike Haskell, Go wasn't designed for teaching. It wasn't designed for research.
Go was designed for writing production software that needs to be reliable.
>So building production software is stated as 3rd most important goal.
Ehrm, no? It is to be taken with no implicit meaning on ordering, i.e. teaching == research == applications, more or less.
All of these priorities are weighed in when there are talks in the community about removing or adding features.
Haskell is a lot better for writing _reliable_ software. It just has a higher barrier to entry, if you come from an imperative background (not much if it's your first language).
>Unlike Haskell, Go wasn't designed for teaching. It wasn't designed for research.
Several times I've heard mentioned that the strength of Go was the simplicity and on boarding new developers, along with them not getting confused about what code means. I'll agree it certainly wasn't designed for research though, since it seems to want to ignore the progress in CS over the last 20 years.
Haskell is very serious about stability, they don't just add or drop features without a long deprecation cycle. Most experimental things are language extensions, which are entirely opt-in.
The main problem Haskell has had for adoption (IMHO) was the lack of good _pedagogical_ material that would hold the users hand and teach them the concepts of the language - there have been superb efforts into fixing this in recent years such as with the Haskell Book etc.
Well, all that really says is that the marketing for Go was successful, and that Go is sufficient to build said infrastructure (just as the languages preceding Go were).
No, it's meant as a warning against the trappings of explosive popularity. A language like C++/Java/JS is difficult to modify because of how entrenched the usage of the language becomes. In that sense avoiding "success at all costs" (which is how it should be parsed) allows "agile" development of the language.
I think the people who make and use Go have had a different experience than you, and judge a language to be suited to production with different criteria. Simplicity, great concurrency (that is, way better than most others even if not the best), speed of compiling, static binary, garbage collection.
I'm not OP, and I don't necessarily agree, but Haskell can produce static binaries, has GC, and has a great story for concurrency. It uses a M:N threading model similar to Go.
But this is an argument more about community than about language design. Granted there are a lot of problems with the Haskell community but deifying poor design decisions as "simplicity" is generally not one of them. For the horror that is string types, though, maybe.
The size of community is a direct result of the popularity of the language.
Haskell had almost 20 year head start over Go. That Go already surpassed it in the number of libraries speaks to the fact that people are picking Go over Haskell.
Following Occam's Razor, people pick Go over Haskell because they find it a better language, where "better" for them is probably different than how you define it, given that you think Go is "poorly designed" and it's a given that "poorly designed" language can't possibly be "better" than even mediocre language and I gather you place Haskell a bit higher than "mediocre".
> Go is a prime example of the "worse is better" doctrine, that's why it's popular
Also known as making trade-offs; a universal engineering theme. Engineering projects that refuse to make trade-offs don't fare too well - you have to pick a point that's acceptable to you on a strength/weight graph or you will be forced to use exotic materials that tend to come with their own cost (yet another trade-off: cost/strength). This is fine in a prototype or in a research paper, but when it comes to production, you will not win the fight against reality.
Edit: For programming languages, I imagine the graphs are roughly features vs. complexity (directly correlated) and then complexity vs. hiring pool size (inversely populated). You have to pick a point on both graphs, and Google picked values some people on HN disagree with and they find that offensive for some reason.
>This is fine in a prototype or in a research paper, but when it comes to production, you will not win the fight against reality.
Indeed, that's the argument I'm making. Where's the disagreement?
>or programming languages, I imagine the graphs are roughly features vs. complexity (directly correlated)
You know Simple Made Easy is a ubiquitous recommendation here and I don't really have anything to add to it. In Haskell as in Lisp all the complex "features" are described in terms of far simpler features. Languages that build in these features explicitly are complex, languages that let you choose don't have to be.
This is why C++ is complex and Common Lisp is simple, even though they have a pretty similar feature set all things considered.
As far as I can tell Go was designed by people who think C got most stuff right, and they intended to make a language that was hard to screw up in. I think they failed here though because neither option types nor generics are that hard to understand and eliminate huge classes of errors.
As I understand it in Go it's pretty common to cast stuff from interface{}. This is a bad pattern because it eliminates type safety. Somebody wrote on HN a while ago, and I'm inclined to agree, that you either have a static type system with generics or you have a dynamic type system. Go is no exception.
I've heard from multiple people teaching Haskell that it's much easier to grasp for people with no prior programming experience compared to those with one or more languages under their belt. It makes sense on some level - core Haskell is about taking plain data and transforming it into something else. Much easier to explain than public static enterprise beans. I think that learning Java/Python/JavaScript/C#/PHP as a first language burdens you with too much baggage, while a lot of what Haskell teaches can be successfully applied regardless of what language you end up working with.
It's truly unfortunate that Haskell got the reputation of being mainly about monoids in the category of endofunctors, and zygohistomorphic prepromorphisms. The core principles are simple, solid, and lend themselves well to writing production code.
Uh, what? Learning Haskell covers a huge surface area, many things you learn are applicable to tons of other languages. How does that make it a poor teaching language?
I'm interpreting "Teaching language" to be the first language students learn. How can one explain the need for monadic IO properly without explaining how regular printf and the like work. Also, Haskell is quite scary to the beginner (Although I personally find it much simpler/more consistent than the Java and C++)
If it's (say) the third language they learn, then Haskell is absolutely perfect for the exact reason/s you have stated. Personally, I actually learnt Haskell by accident (Read SPJ's book about lazy functional language implementation, realized SPJ started Haskell then learnt more from there).
That's only if you're used to imperative languages. Of course even in functional land a slimmed down language like Scheme is probably better for teaching.
