Hacker News Reader

> The top four most common words are "err", "if", "return", "nil". These are each more common than "func" and "string" combined. It's hard to square Pike's comment with that evidence.

Each of those words are extremely common in Go code, even outside of the 'if err != nil { return err }` construct.

It makes sense they'd be more common than 'func' and 'string' because functions usually contain at least one if statement and return statement, and err is probably the most common variable name, and nil is used to represent the zero value of many different types. The 'string' word is only really used in struct fields, function signatures, and some variable declarations, but usually the string type is inferred on assignment.

you can click on the words and `if err != nil {` is the most common pattern in each with `return err` being second place (both by a large margin)

Rob Pike is, very likely, using a different set of programs to judge.

I feel like what you say is tangential. Op didn't say that it isn't logical to see them as most used words. He says that pike's opinion doesn't seem to hold a lot in the light of this evidence.

Go's approach to a lot of things is quite verbose.

Every editor has snippets, or the equivalent, making boilerplate simple to write. And you adapt to reading it pretty quickly - it just becomes punctuation after a while, and you only notice it if it does something unusual.

which is my problem with "try", and why I won't be using it if it gets accepted. It breaks the rhythm of "do something, check for errors, do something, check for errors" that Go code has, and that becomes easy to read.

Just goes to show how out of touch with established programming language research and practice the golang authors are. Now they're re-inventing exceptions, but badly.

It seems a lot of things in golang were done just for the sake of being different, with nothing to back it up.

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

https://news.ycombinator.com/newsguidelines.html

> It seems a lot of things in golang were done just for the sake of being different, with nothing to back it up.

Take an afternoon to go through the Go FAQ [0] (they answer why they don't have exceptions), design documents [1], including this fairly recent one [2] about error handling - they explicitly discuss exceptions and the pros / cons - and that's just what ended up in the design documents / FAQ, there's been at least ten years worth of discussion gone into that beforehand. Do some googling before making accusations like that please.

[0]: https://golang.org/doc/faq#exceptions [1]: https://github.com/golang/go/wiki/DesignDocuments, https://github.com/golang/proposal [2]: https://go.googlesource.com/proposal/+/master/design/go2draf...

I'm aware of their rationales, what I'm saying is that they don't make sense and are dismissive, and have no studies at all to back them up.

It's there in the first link you posted for example, "we believe exceptions lead to convoluted code". Belief here is not sufficient, it must be conclusively shown that it's otherwise, especially given that subjectively speaking it is possible in golang for errors to slip and not be handled at all (I saw it in real code bases), much much worse than any "convoluted" code that exceptions may result in (again it's very subjective - the way golang handles errors results in much longer code that's harder to follow).

"try" as proposed here has nothing to do with exceptions as other languages implement them.

whether that's a good thing itself is another conversation

Not only is your belittling of Go authors gratuitously offensive but it is uninformed as well. That is just one of the many proposals that Go received along the years and there's no intent to implement it at the moment.

I'd say it's uninformed for a completely different reason. Look at the bios of the Go authors. "Out of touch with established programming language research"? Seriously?

"Making different choices than you would have" != "out of touch with research" - especially when they know the research better than you do!

> Look at the bios of the Go authors.

Appeal to authority fallacy. Furthermore, this was evident several times when discussions about things like generics came up. I think they even admitted it at some point.

> Just goes to show how out of touch with established programming language research and practice the golang authors are.

When you said that, was also the appeal to authority fallacy.

Which authority? I observed other languages like Kotlin, Scala, Rust, D, C#, Java, C++ and saw what they have in terms of program design and features.

"Established programming language research". That's a set of authorities, even if you didn't name them.

Kotlin, Scala, Rust, D, C#, Java, and C++ are not language research. They're existing practice.

It's more like an appeal to a consensus if you will, since those languages converged on a set of good established practices (that came out of research obviously) that have actually shown to make a positive difference (e.g. Rust, Scala, Kotlin, and soon Java and C#, have sum types, and pattern matching), and the way they deal with errors (Result type in Rust - where the compiler actually forces you to deal with errors unlike golang, and exceptions in the rest, which again, don't let errors slip through accidentally unlike golang).

The golang authors threw away all that (and are still dismissive of things like sum types) because of, well nothing really to back it up. The same reason they have null pointers whereas all new languages moved away from them, and some like C# are being retrofitted to address them. I think the rationale they gave to having null pointers is that "they're part of the underlying machine" or some ridiculous reason like that, which further proves my point that they're out of touch with established programming research and practices.

> The golang authors threw away all that (and are still dismissive of things like sum types) because of, well nothing really to back it up.

Because of multiple decades at Bell Labs, which was the computer science research facility at the time. And because of multiple decades of experience using many languages to write a huge amount of real-world software. And because of specific problems that they found with using C++ in their specific environment.

Look, you don't think go was the right way to go. That's fine. You even base it on having used go and not liking it. It's good that you're basing your opposition on experience, not just theory. But don't claim that the go authors are ignorant of programming language theory just because of the direction they chose. They are not ignorant at all, and they chose the direction they did with full knowledge of what others were doing. It may turn out to be a mistake, but it wasn't from ignorance.

> And because of multiple decades of experience using many languages to write a huge amount of real-world software.

I'm genuinely interested to see the real-world software you're talking about. Other than UTF-8 (and that's mainly a spec), what's there to show? No, Plan9 is barely used. Most of their work was in C either way.

> And because of specific problems that they found with using C++ in their specific environment.

They found problems with C++, sure, so they made a language that addresses problems with C++ that other languages already did, without looking at what said languages did (e.g. Pascal - and even Java and C# - for fast compile times, and C# and ML-languages for generics). Again, they admitted that they were narrow sighted and mainly looked at C++, not what other languages that actually addressed issues with C++.

The golang authors are not language designers, that's always something to keep in mind whenever looking at what (mostly bad) decisions are being made in the language. The issue is, people are just looking at the brand behind the language and are not thinking objectively, leading to more unmaintainable code bases to deal with. Perhaps it's a good thing for software engineers though, who are going to be paid to clean up this mess :)

Unrelated, but why on earth is "iNdEx" used almost a million times? Is there a joke that I'm missing at play here?

It seems it's generated by the protoc compiler. E. g. https://github.com/weaveworks/common/blob/80ff0769bb38e575cd...

It's funny but this reminds me that my first 'wtf C, you are dumb' moment was trying to use a variable name 'index' in some code in 1989, and getting completely incomprehensible errors in return.

Often when we talk about verbosity in a language, we mean something is needlessly descriptive in a way that can make things tedious or hard to maintain.

Just yesterday I made the joke that you can recognise a Java developer at a party because they start almost every sentence with "public static void". Ha. See, funny?

Go's verbosity feels different, and I don't think it's "verbose". It's clear. It's about making it really clear what is happening.

What surprises me about the proposal is that they think that go's error handling does not reduce the number of errors, because in my experience it does in fact reduce the incidence of run-time errors significantly, and also makes it very clear how to maintain error handling code.

I'm not sure I like the try proposal, but I'm not sure I hate it. What I do know is that the verbosity you're complaining about doesn't feel to me like the same kind of verbosity I complain about in other languages, somehow.

> It's about making it really clear what is happening. You could say the same thing about Java, so your argument basically boils down into “I like Go, and I don’t like Java”. What is clear and important to one person is needlessly verbose to another, what is cryptic to a newcomer might be beautiful and concise to an expert. I’ve encountered idioms that horrified me the first time I saw them which I eventually grew to love, and I’ve been smitten by syntax sugar that I thought would be great and turned out to be a disaster. It’s hard to know how stuff like this will play out, every language evolves its own style and rhythm over time, and sometimes it takes reading and writing a lot of code to find the right balance.

These words are commonly used individually, but that says nothing about how often they appear in a particular order.

have you tried clicking on that link?