[kdkeyser]

I fail to see how else than "primitive" you can call the Go type system: it is roughly what you would get from a language designed in the 70's, and a lot of advances have since been made.

Whether or not these advances make a difference (positive or negative) in production is different question, but I'd rather not use "how much is a language used", as an inherent quality metric for a programming language. Otherwise, I fear we might all end up doing old-school Java, Javascript, Visual Basic and ABAP.

[dimitrios1]

> "how much is a language used", as an inherent quality metric for a programming language.

Define quality. Because what I've realized with the PL-elitist crowd is this almost always boils down to "the ability to be expressive" which is fine but it certainly isn't a complete metric, and, to borrow a common refrain, we've had expressive languages in the 70's as well, we've had s-expressions for a while now. What about other metrics, such as "ability for mass amounts of programmers to program the computer to do the correct thing?" and "ability for programmer to maintain said program?" -- you know, real world quality. My point is, people's usual quality metrics are often incomplete or narrowly defined.

In either case, if Go is so primitive, then why didn't the 70s produce a language like Go? Why did developers who created languages, operating systems, and systems software in the 70s not make Go until the 2000s (you do know who created Go, right?)

I just don't buy this argument, especially having used those "advanced" type systems for many years, sorry.

[AnimalMuppet]

I mostly agree with you, but the claim was that Go's type system was 70s-era primitive. And I think that claim is probably correct. The type system of Go isn't all that sophisticated or "advanced".

But all that says is that the magic of Go isn't in the type system. The couldn't produce-it-until-the-2000s isn't in the type system. The thing that makes Go more used in the real world than Haskell isn't the sophistication of the type system.

I don't see much to argue with in those claims.

[kdkeyser]

I am not sure that my message was completely clear: my point was that despite Go having an objectively old/primitive type system, compared to modern state of the art, that does not preclude it from being a successful "production" language. The value the type system brings is, in my experience, rarely the most important factor in the success/failure of a software project.

My second point was that the popularity of Go (or any language) does not mean that it is inherently a good language, where good can mean, productivity, defect rate, .... Adoption of a language depends on many things, I believe quality of the tools, availability of libraries, and good old marketing (the Google aura around Go has helped in adoption) are often more important. The effort to make an initial, crappy, proof-of-concept is in my experience often decisive for the choice of language. The cost of long term maintenance (where a good type system might bring value) is rarely considered.

For Go, it also hasn't hurt that some of the core developers where being paid by Google to work on it.

The metric of the "ability for mass amounts of programmers to program the computer", is indeed a very relevant one, and I think Go shines there. When reading Go code, I typically find it easy to understand what the goal of the code is. However, "to do the correct thing", is often less of a success: there are off-by-one error and corner cases that have bugs, and reimplementations of the same basic logic. If you have a lot of developers available, you simply have them fix these issues, and your Go project becomes a success.

My point is, that in this scenario, the language itself is of minor importance: success is determined by the fact that you have access to a large pool of relatively cheap labor of reasonable quality (Google or VC funded startups are perfect examples). A 20 or even 50% productivity gain by having a "better" language would simply not matter for the outcome, certainly not if it takes your labor longer to get up to speed.

So, in that context, compared to the alternatives, the quality of Go is relatively high. But I do think that, if during the design of Go they had taken a couple of basic concepts from ML like sum types, polymorphism, and a decent module system, they would have ended up with a language that would make the current Go look unproductive and poor quality, even in that same context. It wouldn't make a difference to Google, but it would make the life of many a developer a little bit more productive and joyful.

And yes, I do know who created Go, but arguments by authority carry little weight.

[eru]

> When reading Go code, I typically find it easy to understand what the goal of the code is.

I have the opposite experience. At a micro-level you might be able to tell what a line of Go code is doing, like manipulating this variable into that state etc, but it's such a tedious language that drowns the reader in code that it can be very hard to see the forest for the trees.

As an example of a deliberately simple language that mostly easy to read, I would perhaps cite Erlang.

In any case, I agree wholeheartedly that Go would benefit from sum types. (Though given the weak type system otherwise, you couldn't even implement a useful `Maybe` in Go. You'd really want parametric polymorphism to make sum types shine.) A way to express immutability would also have been welcome, especially given that they pride themselves on concurrent programming.

[Vampiero]

There's a difference in mentality between people who make either argument.

The "PL-elitist" crowd looks at programming languages from a computer science perspective, while the "PL-pragmatist" crowd (for lack of a better term) looks at it from a workplace perspective. At least that's how I see it.

In other words, one group writes tooling and libraries; the other writes business applications using said tooling and libraries.

One paradigm invites complex, highly expressive code as to minimize the chance of unforeseen errors (even if just by having a smaller codebase), and as to provide a clean and powerful interface that "does more with less".

The other invites simple, highly maintainable code as to minimize the training overhead of new employees and the chance that their lack of rigor might end up accidentally introducing or reintroducing bugs. Furthermore, a simpler language means that new teams can hop onto a pre-existing project faster, because they don't have to scrutinize each LOC to the same extent.

I might be wrong on any or all of this, but that's how I perceive it.

[pjmlp]

Actually it is worse than that, have a look at most languages designed in the 70s, like CLU and Modula-2.

[zingplex]

Worse in what ways?

[pjmlp]

Support for generics (CLI) and exceptions (both).

There are other languages I can take out of the bag like Mesa/Cedar, Interlisp-D, Smalltalk-80, although they are already on the 80's borderline, which then also brings Ada, Standard ML and Object Pascal into the picture.

[AnimalMuppet]

"How much a language is used" is a proxy for "how useful is the language for actually writing programs". And, really, what else do we mean by the "quality" of a programming language? If it's beautiful, but not as good for actually writing programs, then it has quality as a work of art, but less quality as a programming language.

[goatlover]

There's other reasons languages become popular such as platform support, marketing, what people learn in school or as a first language, and what gets you hired. Popularity does not necessarily imply any sort of superiority of a PL usage compared to others.

[AnimalMuppet]

I think you are going too far here. Taken at face value, your post says that for programming languages, there is zero correlation between popularity (use) and superiority (fitness for use). That implies that everyone choosing a language for a project is either stupid or ignorant (not the same thing).

That may offer consolation to those who think that certain languages are the best, and who wonder why those "best" languages are used so little. But I don't think it's true. I don't think programmers are stupid, ignorant, or sheep. I think if a tool offers them advantages, they'll use it.

Perhaps I should qualify: significant advantages. There is a cost to switching. The switched-to language has to be enough better to pay back the cost.

[rowanG077]

This is not actually true. Do you seriously believe Go would have ANY popularity now if it wasn't released and massively marketed by a BigCo?

[Jtsummers]

It probably would've ended up in the same place as Limbo and Alef. Interesting, useful, but of limited use and exposure to the world.

[AnimalMuppet]

"Massively marketed"? Compared to what? C#? Java?

I remember what Sun did with Java back in the day. No, I do not agree that Go has been massively marketed.

I will admit, however, that Go was created and supported by Google, and that mattered. It mattered, not in the publicity, but in the tools and libraries (and maybe even in the tutorials).

[rowanG077]

Compared to C++, Haskell, Python and the long list of other languages not directly backed by BigCos.

So your point is because Java has been marketed more then Go that Go is not massively marketed? If you take the set of all languages and would make a sorted list of how many hours and dollars where spend to market it then I would be very, very surprised to not see Go in the top 5.

[AnimalMuppet]

Define "market".

C++ has vendors behind it. Those vendors make actual dollars selling C++ (or at least tools that work on C++.) When Microsoft markets Dev Studio (with C++ support), is that marketing C++? How about C#?

In contrast, what does Google do to market Go? Put up a website, and put out notices of the next version? When have you ever seen an advertisement for Go? For a tool that supports Go? How about for C++, C#, and Java?

[rowanG077]

I'm being very clear. A language with a big company behind it the likes of Google, Facebook, Microsoft etc. I have defined it two times now. That there are some vendors which make money with a language is very different.

Advertisement is a subset of marketing. Back in the day when Go was "new" You saw daily posts on many programmer focused communities about it. Google bankrolled the entire development of Go. Blogposts of many googlers talking about the language. Google sponsored Go events. The positive image of Google itself at the time of Go initial introduction.

You try to weasel me towards C# and Java when those are not two language I even have mentioned. But since you want to hear about. Yes both of these were also heavily marketed.

[dimitrios1]

Yes, considering BigCo had internal resistance against it for years, and only just recently started to adopt it more for its own internal uses. Comments like this show the clear ignorance of the context surrounding the creation of the language.

[rowanG077]

Ah yes google bankrolled the entire development for no reason. Get real. Go was specifically created for novice programmers at Google to write more safe code then C without them actually having to learn anything new.