Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why people in Google hate Go?

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 144 posts

Re: Why people in Google hate Go?

#91

Post by mauvia »

jjgreen wrote: 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?

IME people recommended it for being more batteries-included in terms of webservice stuff and some multithreading/scaling stuff, as well as having multiplatform support and libraries being compiled into the executable.

The language also seems to be built for the kind of people who think C has no downsides and everyone should write everything as explicitly as possible, which are an audience that normally doesn't get aimed at.

Re: Why people in Google hate Go?

#92

Post by [deleted] »

frankjr wrote: post #56
amelius wrote: post #11

Earlier quoted context omitted.

The same can be said about Rust: its popularity exceeds its scope, because 99% of applications I see that are written in Rust are better off written in a GCed language.

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.

[deleted]

Re: Why people in Google hate Go?

#93

Post by rapsey »

usrbinbash wrote: post #78
rapsey wrote: 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…

> 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?

> Yes, so? De-Referencing a null pointer in Go crashes the program, making the bug very obvious.

At runtime. i.e. production. You think that is just as good as solving the problem at compile time? I certainly don't.

Re: Why people in Google hate Go?

#94

Post by amelius »

frankjr wrote: post #56
amelius wrote: post #11

Earlier quoted context omitted.

The same can be said about Rust: its popularity exceeds its scope, because 99% of applications I see that are written in Rust are better off written in a GCed language.

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.

Python is not a good comparison. It's improving but its runtime system is very slow compared to a modern concurrent GCed system.

Re: Why people in Google hate Go?

#95

Post by elp »

pjmlp wrote: post #41
jjgreen wrote: 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?

Docker (originally written in Java until Go advocates took over), and k8s are what made it popular. Now it is kind of unavoidable in DevOps space for some cenarios. My only complaint is their approach to language design. Inferno with Limbo, Android, Windows Phone, show that there is GC hate, and shipping products to millions of users.

If Docker was in Java it would have been still born / Java universe only.

I don't get the GC hate. If its done properly (like Go) its invisible for 99% of applications and dramatically simplifies things like business logic that don't need to be that complicated or fast.

The real culprit is usually Java's slow startup and memory bloat from the JVM.

Re: Why people in Google hate Go?

#96

Post by demi56 »

pjmlp wrote: post #83
dontlaugh wrote: post #63

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,...

You’re loading your ideas of other languages into Go and with this current Go team that’s wishful features

Re: Why people in Google hate Go?

#98

Post by fallat »

narinxas wrote: post #43
jjgreen wrote: post #33

Earlier quoted context omitted.

As fast as C but with correctness, Rust kind-of owns that space (not a big fan personally).

what about Zig? I think they're a strong contender... it's somehow simpler than Rust then again the correctness guarantee may be weaker??

zig has less memory usage correctness guarantees but its type system is good too.

Re: Why people in Google hate Go?

#99

Post by usrbinbash »

rapsey wrote: post #93
usrbinbash wrote: post #78

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…

> 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? > Yes, so? De-Referencing a null pointer in Go crashes the program, making the bug very obvious. At runtime. i.e. production. You think that is just as good as solving the problem at compile time? I certainly don't.

> At runtime. i.e. production.

At runtime, i.e. initial testing, pre-commit-checks, integration-testing, QA and then production, yes.

So there are a lot of checkpoints where the system can crash before it ever goes live.

> You think that is just as good as solving the problem at compile time?

No, I don't, and I never wrote that I do.

I do think that it's a lot better than not crashing and running inti undefined behavior when dereferencing a null pointer, which is a problem in older languages, and a source of hard to track bugs.

The problem is: solving it at compile time isn't zero-cost.

Languages that pretend that void pointers don't exist are usually more complex than languages that accept their existence as a fact of the underlying hardware. That extra complexity comes at a tangible cost in development time and maintainability. A language that fails early, and with a clear signal, will sometimes crash in testing, and maybe maybe maybe in production here and there, and such crashes may incur a cost. A more complex language will always incur a higher cost in developer time.

Re: Why people in Google hate Go?

#100

Post by EnergyAmy »

usrbinbash wrote: post #79
benterix wrote: post #70

Earlier quoted context omitted.

> It is a lot easier to pick up than C/C++. I would say, "it is a lot easier to pick up than C++" as the language specification is much smaller. I wouldn't be so sure about the comparison to C, though.

The fact that Go doesn't have C's macros alone already makes it a lot simpler. And please don't get me started on writing concurrent code in C.

`//go:generate` is far worse than C's macros
Post reply on HN