I can't even believe this is the kind of comment that gets upvoted on HN nowadays. "Go was made by smart old people and is therefore good. If you don't understand it's good, you're stupid and I refuse to listen to you."
For the record, ignorant does not equal stupid, being a master does not mean you are old, and ignoring negativity (which I should have done here) does not mean I refuse to listen to you. I was simply trying to convey that the rocket has left the launch pad and people will be exposed to the language professionally whether they like it or not. I am finally free of feeling like I need to defend the language to others. It is somewhat liberating.
>For the record, ignorant does not equal stupid, being a master does not mean you are old, and ignoring negativity (which I should have done here) does not mean I refuse to listen to you.
Ignorant might not mean stupid literally, but it still means "you don't know about programming languages" in the context of the comment, which is also bad.
Being a master might not mean you are old, but the masters we're talking about here (Brian et al) are ALSO old.
And saying that you're "ignoring negativity" if you ignore complaints about Go means that you're labelling them as whining or coming from "negative types" instead of accepting the possibility that it can be actual valid criticism.
Thank you for trying to educate me on what I meant by my own comment. Contrary to what you might think, ignorant, in the context of my comment does not mean "you don't know about programming languages" and I know this because it was my comment. I was simply referring to people not having the same professional experiences such that they would appreciate a language like Go.
The crux of the issue is that Go is a local min in a field of possibilities, you may value differently the attributes of various programming langauges which would lead you to some other alternative or local min. I am not passing judgement on others for doing so, but also please be brave enough to admit your ignorance as to why some of us settled where we did with Go. I willingly admit I am ignorant as to why people think other languages are a good idea for general use.
>Thank you for trying to educate me on what I meant by my own comment. Contrary to what you might think, ignorant, in the context of my comment does not mean "you don't know about programming languages" and I know this because it was my comment.
What one means and what one writes/communicates can be two totally different things. The "I know because I wrote it" is a valid argument regarding intent, but doesn't hold the same power regarding what the written thing means to others who read it.
>The crux of the issue is that Go is a local min in a field of possibilities, you may value differently the attributes of various programming langauges which would lead you to some other alternative or local min.
Why would one want a "local min" though?
If anything one would prefer the global maximum or at least a local maximum.
Or is the "min" meant in some dimension that one would actually want to minimize?
fwiw, I found sesteel's comment useful and informative.
(by the way, you might have misread it. I think he didn't mean "generation of masters" as "old smart people" but probably specifically the creators of Go, since they happen to include Rob Pike and Ken Thompson - two people who had separately created the B programming language (immediate predecessor of C), co-created Unix at Bell Labs in the 70's, co-authored a famous Unix book with Kernighan (of Kernighan and Ritchie fame), authored UTF-8 together, etc. They happen to be actual old masters.
They created Go in 2007, from what I heard cleaning up a lot of their old mistakes along the way.)
Being created by Pike, Thompson, and whoever else does not in and of itself make Go better than any other language. It also does not make it immune to criticism in such a way that you should brush off anyone who has anything negative to say about it.
It doesn't make it better, but it's a __very strong hint__ that perhaps I should look more closely at Go. Experts matter, and it would be foolish of me as a developer to discount the experience of these guys -- they've literally been programming for longer than I have been alive.
I respect the creators of Go deeply, because they have been so formative of the industry. It's like being an electrical Engineer, and having Nikola Tesla make a suggestion -- I might not understand all of the lessons, but there's a distinct possibility that these guys are addressing problems I don't yet fully understand.
The guys who designed Go have not designed any other popular languages in the decades between C and Go. They have not produced any modern developer tools or toolchains. Rob Pike's last language before Go was a quasi-DSL called Sawzall, which is a Google internal language for logs processing. I had to use it when I was at Google and frankly, I would have preferred other languages to have been used and didn't find the stated reasons for its creation to be convincing.
If you want to talk to someone who has more modern, relevant experience in language design, go talk to someone like Martin Odersky (Scala) or Andrey Breslav (Kotlin). Andrey in particular has my respect because whenever a language design point is queried he has a well thought out reason for it being that way, often backed by evidence from other languages like C#, Scala, Java, functional languages etc or experience of building modern developer tools like debuggers and IDEs. Both things that Go has a notable poverty of.
In contrast, the justification for Go's design decisions very often come across as arbitrary, or very specific to Google's own codebases. For example Google's C++ style guide bans exceptions, partly because writing exception safe code in the absence of garbage collection is very hard. So not having them in Go won't seem like a big deal to many Googlers. But Go is GCd so that rationale doesn't apply, and the others offered are weak.
Same for lack of assertions. Google has a lot of very, very large slow starting servers and unfortunately at some point some of the engineers on these projects decided that assertions were evil because they had some outages caused by an assertion being hit frequently, causing server restarts. Some code bases there ban assertions as a result. Of course this has a habit of converting a noisy, instantly detected problem into one of silent data corruption or garbage results instead. But it's easier for SRE teams there to measure uptime and response latency rather than correctness of results for obvious reasons, so a bias towards "up but wrong" rather than "down" makes internal political sense.
This of course does not apply to many, many other codebases (in particular, codebases that have exceptions!) and the Go FAQ freely admits that assertions are highly convenient. But the language doesn't have them anyway, because hey, Google C++ sometimes decides not to use them.
It surprises me that you say this, since we (the Go team) spend a huge amount of time and energy talking about our design decisions. But you must have missed it, because the examples you give are wrong.
> For example Google's C++ style guide bans exceptions, partly because writing exception safe code in the absence of garbage collection is very hard. So not having them in Go won't seem like a big deal to many Googlers. But Go is GCd so that rationale doesn't apply, and the others offered are weak.
The rationale for not having exceptions in Go is not about safety, but rather readability. When you're programming with exceptions you need to keep in mind a second hidden path of control flow.
I think you similarly mischaracterise the argument against assertions. In essence, the real reason is that failed assertions produce terrible error messages (that's why Go's testing framework doesn't have them either).
While you're talking to Odersky, ask him about Go. (He said: "I like a lot of the design decisions they made in the language. Basically, I like all of them.")
I didn't say Go bans exceptions because of safety. I said the people it was targeted for won't miss them because they have been working for years in environments where they are not allowed for safety reasons, and the stated justifications for not having them are weak.
The arguments about assertions is a typical example of this weakness. A failed assertion in any reasonable runtime and even in google3 C++ produces a stack trace and a log message indicating what assertion failed. It's then usually easy to go read the code where the problem was hit and start debugging.
In contrast, I find typical Go code to be an unreadable mess of nested if statements and C-style return code propagation. Information is routinely lost and errors ignored. When something goes wrong you don't get a convenient stack trace showing exactly how the program arrived at the place where the failure occurred, you might if you are lucky get a generic error message indicating the general subsystem where something went wrong, or if you're very lucky a log message, but several big Go programs I've seen didn't bother with exhaustive logging on error paths and were difficult to debug as a result.
Compare to other languages (nearly all of them) which have exceptions: I've never once been confused or found code hard to read because of the use of them. That's just not a problem I recognise. But I've benefited from them more times than I can count.
I didn't know Odersky said that. I think that's very polite. Regardless, the language he designed looks nothing like Go, so I guess if he really likes Go's design decisions he has decided that his own language got it all wrong. I don't think he's really decided that.
> When you're programming with exceptions you need to keep in mind a second hidden path of control flow
So ? Developers are completely used to it. Every time there is a conditional statement e.g. if/else we have to think about the other control flow. Likewise every time a method calls another method. And if that method is in a different class then you again have completely lost visibility. Developers are constantly dealing with control flows that go everywhere but straight down.
Java is the 2nd most popular language in the world so pretty sure developers have managed to cope with exceptions just fine.
> Every time there is a conditional statement e.g. if/else we have to think about the other control flow. Likewise every time a method calls another method. And if that method is in a different class then you again have completely lost visibility.
None of that is what I'm talking about. In each case you mention here, it is possible to trace execution by following the code. Each statement passes to the next statement in the block, or—in the case of a branch—very obviously skips to another block or function.
Exceptions provide a second parallel path of execution that may or may not be followed, depending on decisions made in places you know nothing about.
> Java is the 2nd most popular language in the world so pretty sure developers have managed to cope with exceptions just fine.
Arguing "it's popular therefore its good," is a waste of time. Some people obviously like exceptions. I'm just stating the reason Go's designers decided against them.
in addition to what logicallee said, it's common for inexperienced programmers to (poorly) "re-invent" concepts that were discovered in the past by those "smart old people". This is caused by a combination of factors, and one of them is the belief that one can solve a problem single-handedly without studying the fundamentals and previous strategies. Ignoring the work of the masters is a good way to start from scratch and do worse.
Yep! Also, reinventing what existed before (intentionally or by accident) can give you a better appreciation for what was invented in the oast and might be the best way of finding out about it (if you don't know the name, for example).
