Or show me how you would subvert Go's type system and tell me which language you're comparing it to that wouldn't allow similar type system subversion. And no moving goal posts, please. "Type safe" has a certain meaning.
The value of immutability is so overblown, as shown by literally every mainstream language being mutable by default.
Not to mention the perf cost of immutability.
For just one example see https://ayende.com/blog/164739/immutable-collections-perform... (immutable version of dictionary is 30x slower, immutable list is 16-32x slower).
I'm not cherry-picking. This is just the first search result. If you understand how immutability works from first principles, it just does much more work.
Ultimately I wouldn't describe Go as "minimizing bad programmers" but "minimizing a damage that well intentioned but ultimately mis-guided good programers can do to the codebase".
For example I believe that your enthusiasm for immutability is well intentioned but I would rather not take 30x perf hit for theoretically safer code.
Bad programmer will write a bug that can be fixed.
A mis-guided good programmer will write a compile-time parser that only he can understand (possibly only for a week after writing it), will baloon compile times, produces incomprehensible error messages and you won't be able to convince him that a standard recursive-descent parser is 10x simpler to write and read.
Go prevents mis-guided smart programmers from inflicting too much pain on everyone else.
https://donsbot.wordpress.com/2010/02/21/smoking-fast-haskel...
It's been seven years since: that's GHC 6.13, and GHC 8.2.1 is being released soon. Performance is even better now as long as laziness doesn't bite you (which is much less rare than people think).
> you won't be able to convince him that a standard recursive-descent parser is 10x simpler to write and read
I don't know what a "compile-time parser" is, but someone used to a good parser combinator library is going to be difficult to convince.
http://www.haskellforall.com/2017/06/translating-c-parser-to...
It reads like the formal spec of the language. Hand-writing recursive descent parsers isn't fun (given a sufficiently complex grammar) and expecting people to accept it as the One True Practical Non-Ivory Tower Way (and expressing dismay at not being able to convince them otherwise) is suggestive of monoculture, the kind that prides itself on copying code and using wrappers over the two or three first-class data structures that exist in the language for everything.
Functions that accept or return the interface{} type are not type-safe. These are _common_.
Easy concurrency.
Good tooling.
A handy standard library.
Static compiles.
The hype of a "Google language".
You don't need "low conceptual barrier" or anything particularly beautiful about its design to explain its success.
Those are the reasons I use it too.
Good tooling in particular is available because Go syntax is deliberately simple. It's simple for humans and simple for tools.
Go shipped with Go parser in standard library from day 1. Go syntax hasn't changed from that day.
Having Go parser in standard library means that building tools like go get, linters, auto-formatters, code coverage tools etc. is very simple.
Contrast that with C++ or Rust or Swift.
A C++ parser alone (clang) is probably a bigger project than the whole Go compiler. Rust and Swift don't even have a stable syntax yet and as far as I know they don't have the equivalent of Go's ast package.
If Go didn't aggressively tame complexity then it would have ended the same way as Rust or Swift. Sure, it would have generics, but also slow compilation time, language that takes years to reach stability, tooling that is exponentially more difficult to write etc.
That's engineering: making decision about what is more important and accepting that less important things have to be dropped.
If features are most important, then you accept complexity. See Rust or Swift.
If simplicity is most important, then you accept less features. See Go.
I for one am glad that I have a choice.
I would rather have Go than a third language driven by the same ideas and priorities as Rust or Swift.
https://crates.io/crates/syn is the most popular parser crate at the moment.
Only Google never made a good job at promoting it, and it's a dynamic language meant as a better-JS, so not the same market as Go.
>Rust does have all features you listed and of course generics. Both started around 2009 so it is about same age as Go but not as popular among developers.
Rust took until 2-3 years ago to finalize its design and be stable. Go was already stable for years by that point.
And Rust comes with an uncommon, and hard to grasp at first, memory management model which stops many in their tracks -- it's not the presence of generics (or traits, or option types or whatever) that's the issue.
Additionally Dart was betrayed by Google's own teams that decided to invest in TypeScript instead.
They didn't hit 1.0 (and the corresponding backwards compatibility guarantees) at the same time.
So there's always that.
Ditto for C#, but of course C# was pushed by MS as the native solution for Windows, a platform that already had 95% market share.
So asking Go to be popular as Java in 10 years is to live up to expectation that past languages weren't asked.
Go actually just pushes all the complexity into the code you write with it, so I don't buy that that is the reason.
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.
[1] http://haskell.cs.yale.edu/wp-content/uploads/2011/02/histor...
So building production software is stated as 3rd most important goal.
In contrast, here's Rob Pike's talk about Go: https://talks.golang.org/2012/splash.article
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.
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.
Nowhere in that sentence do they claim the list is ordered by importance.
> Go was designed for writing production software that needs to be reliable.
That might be true, but it doesn't actually say anything about how successful they were in reaching that goal.
How would measure that? To me it is simple: lots of cloud related infrastructure is written in that. So it seems successful.
Although, if the slogan has too high of a barrier to entry, I don't know what you'd think of the language itself.
https://wiki.haskell.org/Haskell_in_research
Languages like Go or Nodejs are inherently more production ready and easier to deploy and maintain in production because of their vast ecosystems.
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.
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".
Doesn't mean a thing when Google enters into the picture; and, in a way, it is not exactly true. Go can be regarded as a new version of Limbo.
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.
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.
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.
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).
Is it? Or is it just harder for people who have already learned a mainstream programming language?