Live data from Hacker News

Why people in Google hate Go?

news.ycombinator.com

81–90 of 144 posts

Re: Why people in Google hate Go?

#81

Earlier quoted context omitted.

> Go's type system is much less expressive Please, do explain: what does "much less expressive" mean, in technical terms? What specific data modeling can I not do in Go, and what specific bugs can be caused by that? > and it has null pointers Yes, so? De-Referencing a null pointer in Go crashes the program, making the bug very obvious. Go made the choice to have null pointers (which do exist in silica), and avoid the…

> What specific data modeling can I not do in Go You're getting into the Turing tar-pit. There's nothing you can do in Rust you can't also do in Go, technically. Hell, you can do it all in Brainfuck too, if you so desire. The big thing, though, is ADTs. Being able to say "the value is one of 3 possible values" is a lot easier than saying "here are three values, you should use the non-zero one".

> You're getting into the Turing tar-pit.

I am fully aware of that. My question is, what specific technical problems are caused by Go not having {feature_goes_here}.

> The big thing, though, is ADTs

Except it isn't a big thing, because for the few use cases where an ADT is actually, really, really, REALLY required, they can be expressed in Go using existing language features.

https://go.dev/doc/faq#variant_types

https://eli.thegreenplace.net/2018/go-and-algebraic-data-typ...

Quote: "It seems that Go can do just fine without adding variant types, due to the challenges mentioned in the beginning of the post and the ease with which the major use-cases can be implemented using existing language features." End Quote

On the one hand, yes, this is more verbose. On the other hand, these use cases are simply not frequent enough to justify making the languages syntax and type system more complex.

Again: Yes, Go lacks many features of other languages. That is on purpose. The language is made to be simple, as in "easy to learn, easy to read, easy to refactor, easy to generate, easy to maintain large bodies of code".

Re: Why people in Google hate Go?

#82
post #69

Earlier quoted context omitted.

Go's type system is much less expressive and it has null pointers. An entire giant class of bugs.

> Go's type system is much less expressive Please, do explain: what does "much less expressive" mean, in technical terms? What specific data modeling can I not do in Go, and what specific bugs can be caused by that? > and it has null pointers Yes, so? De-Referencing a null pointer in Go crashes the program, making the bug very obvious. Go made the choice to have null pointers (which do exist in silica), and avoid the…

> what does "much less expressive" mean, in technical terms? What specific data modeling can I not do in Go, and what specific bugs can be caused by that?

This is a good illustration of how to model data using Rust's type system in a way that gives you compile-time guarantees of correct behavior:

https://docs.rust-embedded.org/book/static-guarantees/state-...

> Because we are enforcing our design constraints entirely at compile time, this incurs no runtime cost. It is impossible to set an output mode when you have a pin in an input mode. Instead, you must walk through the states by converting it to an output pin, and then setting the output mode. Because of this, there is no runtime penalty due to checking the current state before executing a function.

> Also, because these states are enforced by the type system, there is no longer room for errors by consumers of this interface. If they try to perform an illegal state transition, the code will not compile!

Re: Why people in Google hate Go?

#83
post #53

Earlier quoted context omitted.

From the point of view from Go folks, we need a PhD for mastering Java's type system.

It has slightly more expressive generics, but otherwise no more complex overall. And no more useful, except perhaps for typed errors. The biggest cause of bugs in Go I find is the weak type system. Nulls, untyped (and overly verbose) errors and the lack of sum types are a big problem.

Proper enumerations, sum types, pattern matching, exceptions, default interface implementations, dynamic loading, class loaders, annotations, compiler plugins,...

Re: Why people in Google hate Go?

#84

> When you search "golang" on google for a long time, the question "Why people hate Go?" comes up at the top. I just did. Here are my top10 results: https://go.dev/ https://en.wikipedia.org/wiki/Go_(programming_language) https://github.com/golang/go https://de.wikipedia.org/wiki/Go_(Programmiersprache) https://gobyexample.com/ https://twitter.com/golang https://github.com/golang https://www.geeksforgeeks.org/go-progr…

You are right. But until last weekend, it continued to appear. It currently does not appear in queries made within Germany.

Re: Why people in Google hate Go?

#85
post #83

Earlier quoted context omitted.

It has slightly more expressive generics, but otherwise no more complex overall. And no more useful, except perhaps for typed errors. The biggest cause of bugs in Go I find is the weak type system. Nulls, untyped (and overly verbose) errors and the lack of sum types are a big problem.

Proper enumerations, sum types, pattern matching, exceptions, default interface implementations, dynamic loading, class loaders, annotations, compiler plugins,...

Java sum types and pattern matching are almost impossible to use in practice, sadly. Exceptions aren't a good thing, it's only good that they're typed. Go has exceptions too, they're just used rarely.

The rest is not very interesting or particularly complex.

Re: Why people in Google hate Go?

#86

I worked on Go at Google for a couple of years. First of all, I can't really parse your question, but I'll try to answer what I think you're asking. Go isn't hated at Google – there's just a lot of other code in other languages. C++ and Java are the two most popular, with Python probably rounding out the top three. Go would probably be number 4 (discounting Javascript, because I'm really focused on backend or infra t…

There is a tragicomic story that I think is related to this question.

Quote from Ian Lance Taylor (Google Principal Engineer)

"Now a bit of personal history. The Go project was started, by Rob, Robert, and Ken, as a bottom-up project. I joined the project some 9 months later, on my own initiative, against my manager's preference. There was no mandate or suggestion from Google management or executives that Google should develop a programming language. For many years, including well after the open source release, I doubt any Google executives had more than a vague awareness of the existence of Go (I recall a time when Google's SVP of Engineering saw some of us in the cafeteria and congratulated us on a release; this was surprising since we hadn't released anything recently, and it soon came up that he thought we were working on the Dart language, not the Go language.)"

https://groups.google.com/g/golang-nuts/c/6dKNSN0M_kg/m/EUzc...

Re: Why people in Google hate Go?

#87
post #74
post #56

Earlier quoted context omitted.

Except when you actually enjoy things being fast. For example, HTTPie easily adds 0.5-1s delay to every request because it's written in Python, especially on the first invocation. xh ( https://github.com/ducaale/xh ), on the other hand, starts immediately because it's written in Rust. I very much like this trend.

I don’t know when you last tested the start-up time, but we significantly improved it in HTTPie CLI 3.0 [0]. Now it’s still slower by ~0.1s. $ time http --version 3.2.2 real 0m0.113s user 0m0.087s sys 0m0.020s $ time xh --version xh 0.18.0 -native-tls +rustls real 0m0.007s user 0m0.002s sys 0m0.002s [0] https://httpie.io/blog/httpie-3.0.0#speed-ups

> Now it’s still slower by ~0.1s

Not for me. Printing HTTPie's version takes longer than to finish a real http request with xh. I suspect it's because I'm testing it on a relatively old server where the differences are even more pronounced.

[link redacted]

I'm using HTTPie 3.2.1 because Arch doesn't have the latest version available but based on the release notes that shouldn't make a difference.

Re: Why people in Google hate Go?

#88
post #20

Earlier quoted context omitted.

I don't use Go since it's from Google but I wouldn't say that Go / Java can't be used for performance critical stuff? There are a lot of values that goes into "performance critical stuff". For me, it can mean a chat app / money transfers etc that is performance critical but is is of course not as critical as in flight software or other system control software where GC could mean deaths.

I meant speed-critical by that, sorry if that was unclear. I see opinions like "1/3 the speed of C" bandied around, not bad but means a big model run takes three days rather than one.

"1/3 the speed of C"

Of course C can be is 1/3 of the speed of C, if the C is written by two different people. An average Go programmer might very well produce faster code than an average C programmer, if Go has better tools for doing normal things fast in an easy and obvious way

Re: Why people in Google hate Go?

#89
post #61

IMHO the hate comes from golang looking more like a better python than a better C. Onboarding of new people is extremely fast, but lack of features will result in seniors hitting a wall on what they can do and guarantee with the language. While go tooling great, you still have to test for most of the edge cases that C and python have: nullpointers, lack of proper enums/typesafety. This is commonly reflected in the te…

Go is a lot closer in target market to Python than C and I can take a mostly competent python programmer and get them to a mostly competent Go programmer fairly quickly. Rust is all very wonderful but it's too hard for juniors to become productive in any reasonable time frame.

Go might be type unsafe compared to Rust but its staggeringly more type safe than any of the interpreted languages. Then you also have about the same speed of Java with instant startups and no memory bloat as a general purpose backed language its great.

I would sell my first born to get the ? operator for error handling that Rust has though. The "if err!= nil" stuff bugs the hell out of me.

Post reply on HN