Live data from Hacker News

Why people in Google hate Go?

news.ycombinator.com

131–140 of 144 posts

Re: Why people in Google hate Go?

#131
post #32
post #5

Go puzzles me. It's slower than C/C++/Rust and GCed, so not really suited for performance critical stuff. No OO so not really suited for larger complex applications. So for smaller not-performance-critical programs, why not Python, Typescript etc? It seems that its popularity exceeds its scope, or am I missing something?

Why does it need to be the best in one single metric when it can be great in many? It is an order of magnitude faster than Python. So it is well suited for performance in many cases. It is a lot easier to pick up than C/C++. So it is well suited for smaller programs. I can see Go as a very good middle-ground.

> It is a lot easier to pick up than C/C++.

That's why corporations like Google invent "middle-ground" languages.

Go from Google

Java from Oracle

C# from Microsoft

These companies need some performance, but they can't hire enough C/C++/Rust devs (not enough exist). They're flush with JS/Python devs, but those languages are too slow.

So they invent these abominable "middle-level" languages, with their insane bloat.

For myself, I'm not interested in mediocrity to serve corporate interests, so I don't touch them. :p Extremes only: Python and C; Ruby and Rust; JS and C++.

Re: Why people in Google hate Go?

#133
post #124

Earlier quoted context omitted.

The higher cost in developer time is a myth. Because the type checking seriously helps you out when you are changing existing code and it results in much fewer bugs out of the gate. Sure the language in its totality is more complex. At least compared to Go or C. But nothing is forcing you to use every feature of it.

> The higher cost in developer time is a myth. And yet, Go is a huge success in the industry, and one of the main reasons often given for chosing Go over a competing language, is how easy it is to get things started, how easy it makes the onboarding process, and how accessible and maintainable the code is. > the type checking seriously helps you out when you are changing existing code If you have Algebraic Datatypes…

You're a zealot and your comment is a polemic, not any kind of reasoned discussion of the advantages and disadvantages of one language as against another.

Re: Why people in Google hate Go?

#134

Earlier quoted context omitted.

What it means in technical terms is what I just told you: Rust's compiler will not let you forget to handle an enum variant. Go's compiler can't do that because the type system can't handle it.

> Go's compiler can't do that because the type system can't handle it Correct. And that isn't a disdvantage. The fact that Go's type system "cannot handle that" directly in it's type system (functionally, the language itself can handle that easily enough, as shown by the article I linked above) is a choice, which results in a simpler language. And I still haven't seen any specific problems that would be prevented if…

> specific problems that would be prevented if Go included this feature directly in the type system

I keep telling you the specific problem that would be prevented. You can't forget to handle an enum variant. That is a specific problem that is prevented in Rust, but not Go. And no, the language doesn't "handle that easily enough".

Update an enum in Rust with a new variant? Your code won't compile until you've updated everywhere that matches against it. Do something similar using the technique you linked in Go? Good luck, hope you don't introduce any bugs by forgetting to handle it somewhere.

Re: Why people in Google hate Go?

#135

Earlier quoted context omitted.

> Go's compiler can't do that because the type system can't handle it Correct. And that isn't a disdvantage. The fact that Go's type system "cannot handle that" directly in it's type system (functionally, the language itself can handle that easily enough, as shown by the article I linked above) is a choice, which results in a simpler language. And I still haven't seen any specific problems that would be prevented if…

> specific problems that would be prevented if Go included this feature directly in the type system I keep telling you the specific problem that would be prevented. You can't forget to handle an enum variant. That is a specific problem that is prevented in Rust, but not Go. And no, the language doesn't "handle that easily enough". Update an enum in Rust with a new variant? Your code won't compile until you've updated…

> And no, the language doesn't "handle that easily enough".

Yes, the language handles it easily enough. ADTs, despite being the single most used example of "what Go doesn't have" since the language got generics, are not very common outside of the ML-derived-language world.

If they occur at all, they are usually used in a few very specific places. An example are AST types that are used in exactly the part of the parser handling that type.

Re: Why people in Google hate Go?

#136
post #124

Earlier quoted context omitted.

The higher cost in developer time is a myth. Because the type checking seriously helps you out when you are changing existing code and it results in much fewer bugs out of the gate. Sure the language in its totality is more complex. At least compared to Go or C. But nothing is forcing you to use every feature of it.

> The higher cost in developer time is a myth. And yet, Go is a huge success in the industry, and one of the main reasons often given for chosing Go over a competing language, is how easy it is to get things started, how easy it makes the onboarding process, and how accessible and maintainable the code is. > the type checking seriously helps you out when you are changing existing code If you have Algebraic Datatypes…

> And yet, Go is a huge success in the industry

Success of a technology is more often than not dependent on who is behind it. Anything by google will likely see a lot of uptake.

Every language has a story. Some of it is bull some not. Best to try and be objective and not drink every drop of the koolaid.

Re: Why people in Google hate Go?

#137
post #32

Earlier quoted context omitted.

Why does it need to be the best in one single metric when it can be great in many? It is an order of magnitude faster than Python. So it is well suited for performance in many cases. It is a lot easier to pick up than C/C++. So it is well suited for smaller programs. I can see Go as a very good middle-ground.

> It is a lot easier to pick up than C/C++. That's why corporations like Google invent "middle-ground" languages. Go from Google Java from Oracle C# from Microsoft These companies need some performance, but they can't hire enough C/C++/Rust devs (not enough exist). They're flush with JS/Python devs, but those languages are too slow. So they invent these abominable "middle-level" languages, with their insane bloat. Fo…

> Java from Oracle

Oracle acquired Java with Sun Microsystems, it was originally designed for embedded systems and the dream of “write once, run everywhere”.

The idea of a “hardware JVM” always fascinated me, I seem to recall some parallax microcontrollers that could run a subset of jvm bytecode back in the 90s, but never actually got to play with them.

Re: Why people in Google hate Go?

#138

Earlier quoted context omitted.

> specific problems that would be prevented if Go included this feature directly in the type system I keep telling you the specific problem that would be prevented. You can't forget to handle an enum variant. That is a specific problem that is prevented in Rust, but not Go. And no, the language doesn't "handle that easily enough". Update an enum in Rust with a new variant? Your code won't compile until you've updated…

> And no, the language doesn't "handle that easily enough". Yes, the language handles it easily enough. ADTs, despite being the single most used example of "what Go doesn't have" since the language got generics, are not very common outside of the ML-derived-language world. If they occur at all, they are usually used in a few very specific places. An example are AST types that are used in exactly the part of the parse…

They're used all over the place where they're available. More languages are incorporating them exactly because of how useful they are.

I expect much like generics, we'll get some new version of Go eventually that half-asses ADTs, with much fanfare celebrating how they were totally always going to do it, they just needed to perfect it.

Re: Why people in Google hate Go?

#139

Earlier quoted context omitted.

> Go's compiler can't do that because the type system can't handle it Correct. And that isn't a disdvantage. The fact that Go's type system "cannot handle that" directly in it's type system (functionally, the language itself can handle that easily enough, as shown by the article I linked above) is a choice, which results in a simpler language. And I still haven't seen any specific problems that would be prevented if…

> specific problems that would be prevented if Go included this feature directly in the type system I keep telling you the specific problem that would be prevented. You can't forget to handle an enum variant. That is a specific problem that is prevented in Rust, but not Go. And no, the language doesn't "handle that easily enough". Update an enum in Rust with a new variant? Your code won't compile until you've updated…

Easily handled by adding a linter. Like you pointed out, that's an easy place to make mistakes, and this regularly catches them for us https://github.com/nishanths/exhaustive

Re: Why people in Google hate Go?

#140

Earlier quoted context omitted.

> And no, the language doesn't "handle that easily enough". Yes, the language handles it easily enough. ADTs, despite being the single most used example of "what Go doesn't have" since the language got generics, are not very common outside of the ML-derived-language world. If they occur at all, they are usually used in a few very specific places. An example are AST types that are used in exactly the part of the parse…

They're used all over the place where they're available. More languages are incorporating them exactly because of how useful they are. I expect much like generics, we'll get some new version of Go eventually that half-asses ADTs, with much fanfare celebrating how they were totally always going to do it, they just needed to perfect it.

> More languages are incorporating them exactly because of how useful they are

No, more languages are incorporating them, because most languages operate under the assumption that "more-is-better" is a good design maxime, also known as the "everything-and-the-kitchen-sink" method.

Resulting in exactly the opposite of what Go is, with extreme success, doing.

Fun fact: That methodology in other langages is what made Go's success possible in the first place.

> I expect much like generics, we'll get some new version of Go eventually

I expect the exact opposite, precisely because of generics. Because it has been some time now since they were implemented, and lo and behold: They are rarely used in most codebases, because as it turns out, the people saying "Outside of some collection-types, generics are almost never required" were right in the first place.

Post reply on HN