Why people in Google hate Go? | Hacker News Reader

Why people in Google hate Go?

28 pointsaltun140 comments

When you search "golang" on google for a long time, the question "Why people hate Go?" comes up at the top.

Now the blog post "A new way to bring garbage collected programming languages efficiently to WebAssembly" written by the team of V8 (JavaScript and WebAssembly engine) on the official website of Google has appeared.

https://v8.dev/blog/wasm-gc-porting

When I saw in the first paragraph of the blog that "we will get into the technical details of how GC languages such as Java, Kotlin, Dart, Python, and C# can be ported to Wasm" the question "Why people in Google hate Go?" arose

View on HN

Go is an extremely productive language in our experience (large majority of the back-end is in Go).

Go excels in tooling and code sharing, and onboarding developers with Go is efficient.

It also has an extremely small runtime footprint, reducing ecological footprint and server costs :) An average JVM needs 500+ MB of RAM, whereas our average Go microservice hovers around 25 MB.

Last but not least, it is not tied to the existing C ecosystem, which is a HUGE value add in containerized environments where in the majority case you can make a Docker image that is based on `scratch`.

Of course there are some quirks (lack of try syntax for example), but Go programs are also simpler to comprehend due to intentional exclusion of AOP, try-catch, etc.

Lastly, the interface system is probably the most straight forward and simple for general programming :)

You can actually fine tune to run the jvm at the same memory footprint as go. It’s just not easy to do so. Especially since it lacks structure/value types.

> Last but not least, it is not tied to the existing C ecosystem, which is a HUGE value

They also provide their own crypto within the standardlib. No openssl needed.

>An average JVM needs 500+ MB of RAM

We are running small services with heap size under 100 MBs and is absolutely possible with new JVM versions. If you want ever smaller without JIT, native image is also an option. Moreover in most scenarios, JVM provide better peak performance. So here is a tradeoff

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 tech).

Go's performance is not as good as LLVM derivatives, but that's not what it tries to be. It's a simple language, that tries to be as helpful as possible to the programmer. I describe it as a big-boy python, but think of it as "the C I always wanted."

Generally, I don't need the performance of C++. I think lots of people that think they do are probably wrong, but I try to not argue on the internet. If I need to get something done, and get on to the next thing, I use Go. Do I leave cycles on the floor and have (very small) GC pauses – yes, but I get my stuff done, and IMO it's a small price to pay.

Use whatever language helps you get your stuff done. Stop arguing over languages.

Having said that, if the question is, "why aren't the WebAssembly people mentioning Go?" I don't know. Go's supported WASM for a long-time, and the people inside Google who care about WASM care about Go. There is new stuff in WASM not really taken advantage of in Go, but Go is also a strange animal with a strange stack model, and it takes time. I would think, as with all things Go, it'll be there, but it will take a little time, be thorough, complete, well thought out, and maintained roughly forever.

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

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?

K8s is it's lifeline.

Exactly. This is exactly my thought, my only reason for learning Go Lang at all, was/is because of Kubernetes and much of the tooling around it.

Interesting -- thanks for that

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.

Are weapon targeting systems and battleships speed critical enough?

https://www.ptc.com/en/products/developer-tools/perc

"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

This talk by Rob Pike answers some of your questions: https://go.dev/talks/2012/splash.article

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 suddenly do need performance and predictable latency but all your software is written in python. Its always funny how these performance requirements just creep up on you like that.

C# is GCed but has 'unsafe' blocks.

Alonside value types, manual memory allocation if needed.

Not all GC based languages are made alike.

Yup, and (monomorphized) struct generics, first-class SIMD vectors and ability to transparently work with memory ranges because Span<T> can also wrap T* + Length from unmanaged code, which lets you directly plug whatever data you got from C/C++ dependency into most CoreLib APIs.

In this regard, Go is far inferior as a systems programming language.

Yeah what we really need is a GCed language that allows you to implement parts in no-GC mode. And ideally where you can iteratively migrate GCed parts to no-GC parts when required.

Anyway, Python is not a good comparison, as performance is not one of its main qualities.

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

Still no story for UAF, and the community is against shipping binary libraries.

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

> Rust kind-of owns that space

True. But it's a pretty small space to be in. And there are good reasons for that:

a) The only correctness Rust can, mostly, guarantee, is that there won't be unexpected data races or memory bugs. While this is proudly announced often and loudly, it also isn't the most common problem in code...logic bugs...against which the rust compiler can do as little as any other language.

b) Rust can only give these guarantees because it is ALOT more complex than C. That means harder to read, harder to write, harder to learn. And developer time matters. Alot. If I can already ship features, while my competition is still stuck in onboarding, it won't matter if my code has the odd memory bugs...those can be fixed...I will already have the market to myself.

> a) The only correctness Rust can, mostly, guarantee, is that there won't be unexpected data races or memory bugs. While this is proudly announced often and loudly, it also isn't the most common problem in code...logic bugs...against which the rust compiler can do as little as any other language.

A powerful type system helps quite a lot with logic bugs actually.

> A strong type system helps quite a lot with logic bugs actually.

A static type system does, and all the languages that Rust has to compete with in its space, have one.

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 complexity of languages who pretend that null pointers don't exist.

It's a tradeoff, and a very good one at that.

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

That link shows the Go type system's lack of expressiveness. You have to manually include things like the default case. Rust's compiler will do exhaustiveness checking for you, and you can't just forget about it.

Also, it's not about ADT's being required. They're preferred, and Go's type system suffers for their lack. Go is a living, breathing example of the blub paradox in action.

> That link shows the Go type system's lack of expressiveness.

And I ask again what that is supposed to mean in technical terms, and what specific problems would be prevented if Go's type system was "more expressive".

> They're preferred

I am fully aware that for every given language feature, there are people who prefer that feature. And many languages reacted to that by including everything and the kitchen sink. That made many languages very "expressive", but that expressiveness comes at a cost: It also made the languages themselves become bigger and more complex.

Go isn't about having as many features as possible though. Quite the opposite, it's about having as many features as necessary, and as few as possible. Why? Because it keeps the language small and easy to learn and the code easy to read and maintain.

And to me (and judging by the sucess of Go I am not alone in this), that is a lot more important than a bit more "expressiveness" in things that one may come across every now and then.

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 Go included this feature directly in the type system. I have, however, seen a lot of extra syntax that Go doesn't need to support in its compiler, Go students don't have to learn, and Go devs don't have to worry about.

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

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

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.

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

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

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

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 in your codebase, which is not a given. Having a simple, easy to read language helps me out ALL THE TIME.

> But nothing is forcing you to use every feature of it.

And nothing forces C developers to use so many macros that their libraries resemble a completely different language where everything I thought I learned about C flies out the window. Nothing forces Python devs to use nested dictionary-comprehensions, that are, ironically, completely incomprehensible. Nothing forces C++ developers to use generics everywhere, regardless of whether they are actually needed or not.

And yet, that is, unfortunately, what is often happening in the wild.

The point here is; If a language offers X, then X will be used. And it will be used in smart ways, it will be used in unnecessary ways, and it will be used in not-so-smart ways. It will be used when it makes sense, and when it absolutely doesn't.

The thing the developers of Go figured out, and which, in hindsight, is surprisingly obvious, is that there is exactly one, and only one, foolproof way to prevent that from happening: By not having X in the language.

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.

This isn't a discussion about the advantages or disadvantages of languages.

This is a discussion about whether Go "misses" things, or "lacks" things, or if it's designed to not have these things, and if there is a reason why that is.

I have demonstrated, and provided arguments, for why the latter is the case. Aka. the exact opposite of "polemic".

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

> Anything by google will likely see a lot of uptake

Disagree.

https://www.failory.com/blog/google-failed-products

I went from Erlang to Rust and frankly I would not say Erlang is more productive, despite being a very high level language. When building a non-trivial system one should think about total cost of ownership.

A Rust program is by default going to be CPU and memory efficient. It is not likely to negatively surprise you in production with weird bottlenecks and unexpected behavior.

The time invested in producing a solution which is statically typed, pays of in spades when it is time to refactor or change something (which is pretty damn often if it is your product). Refactoring a Python/Erlang/Elixir/C/PHP solution is a major PITA and fraught with new bugs.

The time spent optimizing solutions in high level languages when they are falling on their face in production is generally ignored and extremely common. You do not have to be github to face performance problems in Ruby.

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.

Gotcha. Would you mind checking if you happen to have PyOpenSSL installed inside the Python environment HTTPie runs from?

I did not have it installed. Installing it did not make a difference. If it's of any help, here's a profile generated using cProfile. [link redacted]

Thanks!

Yeah, I agree on that. In the nineties, basically the only general purpose language was C, with C++ growing in pains (and then extending uncontrollably) and Java promising to get better but having its own issues at that time. So people who needed to get their job done (efficiently) just used C, like Torvalds.

At that time, this new Python language was a curiosity. It was nice that you could easily replace dozens of C code with one line of Python but everybody was aware it's too slow. However, this window shifted with time. The perceptions of "fast" and "slow" changed for various reasons such as network delays so Python became acceptable in many areas it would be dismissed otherwise. To the point it became the no. 1 language now.

But we are not in the 2000s anymore. We do have powerful, batteries-included languages that are faster than Python. So I expect with time, large parts will be rewritten. However, the area related to scientific computing will stay with Python, just like Fortran programs continue to be used today.

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

No OO?

And still has null pointer exceptions. I could see a role for it in between like rust and python if it had a sane type system.

I really like Go but the type system is just a bit too weak in my opinion. It is the biggest issue I have with the language ( and the fact that errors are basically untyped, you can type them but no one does…)

Not seeing how OO makes a language more suited for complex use cases. If you said OO approaches add complexity to any use case, I would agree to that.

It compiles down to a single binary and is relatively easy to write. I think that is the reason it is such a popular language for CLI tools.

You will never have an issue with missing dependencies or outdated runtime.

Nothing is stopping anyone from compiling C or C++ code into a single static binary too. This argument is bull$%!#.

Go is basically a very specialized language for writing small network services that are supposed to run on Linux. If this isn't your use case, then don't use go, but if it is, then golang is nice. Mostly the runtime and tools, not the language itself, though

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

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

That's just a glorified make rule. There's nothing inherently hidden or complex that it generates, unlike macros

I have written Go professionally for close to 10 years. The only time I encountered go:generate is in yacc parsers deep within libraries. A regular Go developer might go for years without realizing that it even exists. Compare this to C macros.

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

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

OOP is generally a bad idea, so lacking it is not a downside.

The bigger problem is the weak and inexpressive type system, which is no better for C or Python.

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.

Nah, that is what anti-Java folks wish for.

Java is so bad that Kubernetes + WASM containers is basically redoing application servers 20 years later.

> so not really suited for performance critical stuff.

What "stuff" is that exactly? Because Go is designed primarily for backend services and microservices. Considering how much backend software is powered by Python, Java, or *retching sounds* PHP, I highly doubt that is a major consideration in that area.

And even when performance actually does matter to an extend where it becomes a more pressing issue than network latency, Go code performs incredibly well and is more than a match for most requirements.

> No OO

How do you figure? I can write in a completely object oriented style in Go. Also, OO is not a prerequisite for large complex systems, and quite often strict adherence to it can make code much harder to maintain than it needs to be. Maintaining large complex systems requires, first and foremost, code that is easy to grok and maintain. And regarding that particular area, Go runs circles around any major contemporary language, including Python.

> It seems that its popularity exceeds its scope

Considering how widespread it is by now, I highly doubt that.

It's fast enough for most applications. Python and Typescript are unmaintanable. Everything around them breaks as the time goes by. I'd argue Python is not suitable for anything that spans more than one file or one week. I don't have enough experience wtih Typescript to hate it as much, but I know I spend most of my time fighting with the tooling. Again, unless you are writing a fresh application that is fine to throw away after a year, Typescript is not it.

Go excels in that it is so simple. As the saying goes, you mostly read code, not write it. Go is very easy to understand and review. Which is what you do mostly when working on complex systems in teams. It's extremely easy (and fast) to build and deploy unlike the languages above. That's why companies use go. Not for personal projects, not for drivers, and also probably not for corporate monoliths that require a suit and a tie to contribute.

Heh, my brother-in-law is a Java suit-and-tie dev, he was telling me that he'd been working on a project for 18 months, the specifications were almost complete and he'd be starting on the coding soon. Being in the startup space I was slack jawed, it's a half-day planning and then start hacking up the MVP for me. Worth noting that he drives a BMW.

Go is easy to understand like Brainfuck is. One singular piece is easier to read, but you've just spread the complexity around, making it hard to see the bigger picture.

It's really nice to use though, I never liked python and its environment, coming from C go feels like home to me, it's simple and it just works. I never had headaches to setup and run things like I had with python and js.

Performance is good enough for most jobs, we're not all working on the bleeding edge, a lot of jobs are more akin to code monkeying basic CRUD

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.

> No OO

Are you referring to Object Oriented programming? And if so, why not?

Go is:

* Easier/safer than C

* Less dangerous than Javascript (statically typed and a good standard library)

* Much faster than Python

I think it's an excellent middle ground, compromise language. It's the centrist candidate of programming languages. Not the best at anything, but on average better than most.

I'd add that it also ships with an incredible toolset alongside the installation, has a fully featured standard library, cross compiling is typically painless, and you get a single binary executable out the other side.

You just cited C, how's not having oop a requirement for big apps?

Also, unless inheritance is what you mean by oop, it supports the other usecases of oop

> So for smaller not-performance-critical programs, why not Python, Typescript etc?

I can compile my go application down to a single, static binary that can run in a distroless container. The packaging/deployment simplicity of Golang appeals to me much more than Python, TypeScript, etc.

Also the developer tooling is first class and sustained backwards compatibility is top-notch. I can pretty much always upgrade the version of Go 1.x I target and have 0 worries in the world. Meanwhile in Python and JS land, the dependency management problems are a nightmare.

I am not a functional programming fanatic, but I do appreciate all the functional constructs making their way into less esoteric languages. Such as map/reduce and in general working with immutables.

Golang does not have this and it makes me feel like programming with only one hand. In particular when working with data and aggregations.

I am prepared to be corrected, I have only looked briefly at golang, so I am happy to give golang proponents a chance to shine!

I felt very similar when I started working in Go last year. Coming even from languages like Typescript and Python which are most definitely _not_ functional but do have some of the niceties like map/filter/reduce, I was missing it a lot in Go.

What I also found was that there was a whole class of errors that I hadn't seen in years due to mutable state and poorly written for loops/ranges when compared to map/filter/reduce usage.

We introduced `samber/lo`[1] which provides a lodash-like library, generics compatible, to Go. This has been a big step-up and has improved my experience with writing Go immeasurably.

My colleagues now (kindly) joke every time they see a PR from me that includes a lot of samber/lo usage that I'm slowly replacing every for loop I encounter.

[1]: https://github.com/samber/lo

Thank you! I will probably use it when I run into golang again.

I am with you. Ever since working extensively with SQL for a while my go-to paradigm has been "programming without for-loops". It just magically removes the bugs.

The problem here, as you also hint, is that there will be a clash with the existing culture and codebase. And that may not be a small thing, even though you co-workers seem to treat you in a good way.

They don’t mention go in that list of languages that now can be compiled for the browser because go already has a wasm backend (GOARCH=wasm)

There are the languages people shit on, and the languages nobody use.

Go is far from perfect, but I’m productive with it, it’s expressive enough that it’s both easy to write AND read, it’s performant enough, easy to build and deploy, and most importantly, it gets shit done. I don’t need more, but the Go team still delivers great updates every 6 months or so.

> 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-programming-language-introd...

https://www.freecodecamp.org/news/what-is-go-programming-lan...

This continues down for dozens of results. Articles, Frameworks, Tutorials, Projects.

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

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 tests that have to check for lots of trivial things.

Rust is much more difficult to learn, but the amount of things you need to test is drastically reduced, and seniors appreciate that.

What we see in our company is that juniors will find go wonderful, seniors dream of switching to Rust.

The hate probably comes from high expectations (especially coming from python/C), followed by hitting a feature wall due to how opinionated (and slow to adopt new features) golang is.

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.

> When you search "golang" on google for a long time, the question "Why people hate Go?" comes up at the top.

I don't see this article in the first page when searching for golang. Maybe the results is personalized based on your search history?

> Why people in Google hate Go?

I really doubt that. Most developers I know, that worked with Go for a while, love it for its simplicity and tooling.

> When you search "golang" on google for a long time, the question "Why people hate Go?" comes up at the top.

What does this mean? Where do you see this? Also, I don't believe that question comes up verbatim, since it's not grammatically correct.

Previously, golang sub reddit came to the top in golang searches. The first title on the subreddit was "Why people hate Go?" was the title. Now go.dev comes first and reddit is below without title.

When you search reddit golang, the title continues to come first.

I see. Reddit was the key word.

It has a richest std lib with quite good performance which makes it suitable for a lot of use cases where one wants to reduce dependency. I also find it quite easy to learn. Personally use for all web products I build as I have gotten the hang of it and have a small sort of framework to build products quickly with. And I get to ship a single binary to production.

Related: The State of WebAssembly 2023

https://blog.scottlogic.com/2023/10/18/the-state-of-webassem....

I dont think people in Google hate Go. But I have heard multiple times people in Google hate Ruby.

Well, putting aside arguments based purely on money, what's the fundamental "edge" that Go gives you as an engineer betting you career long term on it that isn't better used in some alternative?

When I was there the only complaint I heard was the golang exceptions to the style guide. In no other language would you be allowed to name a variable a single letter like "r" for example.

"Hate"? What do you mean by "hate"?

Why people outside Google hate Go?

"Why people hate Go?" - https://www.reddit.com/r/golang/comments/mjhf5h/why_people_h...

There’s still no ideal language.

Closest seems something like Zig but it doesn’t seem to be getting much velocity.

I really wish TypeScript had an official native code compiler. It did have one but only for microcontrollers and I’m not sure even that still exists.

Ask HN:

Go isn't a serious language for large systems. The language allows writing shitty code and the community has largely adopted that. Go fanatics will hate this, but you simply can't compare it with the ability to write and maintain in languages like Java.

I'll bite. Why can't you compare it? Is it the class/function on struct thing? Generics? Go-routines not threads? Rob Pike did say once that the GC is deliberately not tunable because a JVM knob-twiddler should not be a job title.

Many reasons including:

* Poor modeling ability (lack of default interface methods, no records, pattern matching, exhaustiveness checks, etc.).

* Error handling is error prone. * Generics are half baked.

* No short hand syntax for passing functions as lambdas.

* No annotations.

* Implicit interfaces make it hard to navigate large code bases because it is very easy to accidentally implement another interface. There are better solutions for the problem they tried to address with structural interfaces. * No string templates.

* The GC not being tunable does not obviate the use cases where it needs to be. Furthermore, Java's ZGC only has a couple of knobs anyway, while giving you the option to use a more tunable GC when your use case calls for it. golang's GC is only tuned for latency at the expense of throughput.

* goroutines are half baked, see Java's virtual threads + structured concurrency for a more manageable approach.

* Observability way superior on the JVM.

* No proper enums.

* No const/final variable declarations.

* Visibility rule are crude. Only public or package private.

* Probably more things I didn't think of at this time.

decent list, to be fair

Can you give an example of 'shitty code'? We've got murmurs of Go being adopted by some teams so if you have first hand experience it'd be really useful

Single letter variables. A terrible pattern the go community picks up.

Single letter variables like `i`, `j`? How `index1`, `index2` is any better?

My guess is that he means, he would prefer variables to be more descriptive. Easier to read and follow.

Eh. Yes and no. I have not worked on a team that enforces that and I do agree with using them for short functions with 1 or 2 types. I do this in python as well

  with open(..) as f:

I have never seen this done in enterprise Go code, and I don't think it's been strongly recommended since the mid 2010's?

For small functions where you can see everything in a single page, this is fine. Though I think they should always be avoided except the most common cases (`i` for index) because keeping a codebase grep-able is a high priority. Using constant, verbose variable names can make tracing through a codebase much easier.

Is that really the best argument against Go lmao ?

I've heard that this is the result of snake-case refugees from C, Python etc. Single letter variables are camel and snake, everyone's happy.

As a counter anecdote, I've worked at two large companies with monsterous Go codebases and they are totally fine to maintain. There is no justification to the claim that Java repos are "easier to maintain" by the above commenter, as we have decade-old Go codebases that doing great.

I'm just as fast/productive in Go (8 years of experience) as I am in Python (13 years of experience), but the resulting code is:

    * more maintainable (enforced typing vs typehints+mypy)

    * faster (compiled vs interpreted)

    * consistently structured / opinionated (until recently we didn't have generics, which meant that engineers often had to do things the "boring and verbose way" instead of the "clever and concise way" which, though frustrating short-term, has proven to be much better for maintainability long-term.

There's no reason that your company can't support multiple languages. Uber has large Go monorepos, Java monorepos, Python monorepos, etc. and they all work in harmony and with different requirements.

This isn't a serious argument, you can write 'shitty code' in Java too. In fact, I've seen more 'shitty' Java than 'shitty' Go, since I've seen far more Java projects than Go projects. It's possible that Go makes it particularly easy, but I somehow doubt that.

OOP languages like Java are not considered to be good.

Considered by whom?

By people who don't like OOP languages.

It's an appeal to (pretend) authority by people who won't or can't make a real argument.

Java also has null and overall a weak type system. They're pretty close in that respect, actually.

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

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.

Word salad, hand waving that Java has indeed a much better type system.

It’s a little better, for sure. It’s nowhere near something sane like OCaml or Rust.

I don’t particularly like Go or Java.

I don’t see what salad has to do with anything I said. Go does have exceptions and unlike Java, they are untyped and rarely used. They’re not great in either language.

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

Not at all, I rather use other languages instead of dealing with frustation.

I apreciate what Go offers as a better C alternative, similar to Limbo's role in Inferno, and that is the only thing I will advocate Go for.

Go was created for an internal promotion of a guy in Google, he already got the promotion I believe, so there's no real use case to keep using it.

You could say the same for most languages

Reply on news.ycombinator.com