2 of 9

Why do Critics RANT against GO?

Like any language Go has its critics, it is good to check out what features idioms and patterns are seen as an issue. To understand and answer them with respect to your own usage of Go.

The highest profile anti-Go rant I Googled is:

Lies we tell ourselves to keep using Golang

Plus developers verbal complains / Reddit rants. Lets address a few of the wider criticisms from this blog post first, then dig into the language …

3 of 9

Mom smokes, so it is probably OK

Primary criticism: People adopt Go just because�it is in use by large companies for significant products. �Management think it must be a sensible choice, without fully technically assessing it.

In this case I would have to say the author may not be a platypus, but his use case, is the oddest Go creature I have come across!��As a Windows system language for integrating into C and C++ … which leads on to his ‘Go is an island’ criticism. �The Go language does not use standard assembly and C compilers that enable easy Foreign Function Interfaces, where as Node, Python and Ruby are all more suited to FFI. ��A standard Go cross language integration I use is via gRPC. But that is cross-system not low level, so not suited to the author’s use case.

4 of 9

Smoke forms a Cloud

Wrong tool - Go for low level Windows ~ Like C# for Cloud Tooling. ��Generic languages DO NOT suit all use cases, else why do so many exist. �Use the right tool for the job.�

THE CLOUD: Docker, K8s, Terraform/Tofu, Pulumi, Rancher, Flux, Argo, Prometheus, Grafana, Istio etc, whichever CSP, all of it Go.�They will expose Java, Python APIs, but to dig deeper than a template generated solution for k8s you need to use kubebuilder in Go. Or code a full Terraform module, it must be Go.

5 of 9

Go is Simple = Good for ProtoTyping =

A core quality is Go is simple, and simple provides RAD, the reason for prototyping.�

The author argues that prototyping is a lie and the code ends up staying in production.

I would argue that if it is deployable and deployed to production then it is by definition not being used as a prototyping language. His argument is about failing to use a prototyping language … so is nothing to do with Go.

If prototyping is required, is that language close enough to Go and difficult enough to deploy to, to make proper prototyping .. and doing it in Go, worthwhile. A common case is hard wired embedded C.�� This is again about properly defining the job, to pick the best tools for it.��On the plus side, the top rant post against Go on the web also cites 3 other features they like …

6 of 9

The Gold Star Language Features

The features nobody can deny Go beats other compiled languages at:

Simplicity�For a performant compiled language, otherwise Python tends to compete here.�
Asynchronous coding is in the core and is elegant�But for cloud, of little use, since each microservice should ideally be a single process per container. I only use goroutines for cron jobs which could be k8s jobs. My primary use is fast parallel tests.�
Core Tooling is extensive and easy to use�- eg. dumping goroutine stack traces using “runtime/debug”�- tests run concurrently by default etc.�
Fast and small�Fast start, performant, with small binary and memory footprint - perfect for a microservice

7 of 9

Java wingers - Reddit Rant (my turn to rant about java!)

Lacks Proper Dependency Injection
Lacks Proper Package management (ie. no Maven)
Domain names in packages
Lack of big stack traces
It not more performant than Java
Its difficult to maintain for large monolithic applications

The limited inheritance of Java and its hack of dependency injection has become not only a desirable design pattern for Java heads, but a golden one. �Java itself doesn’t allow full multiple inheritance, presumably to reduce complex class hierarchy inheritance, since that can become a nightmare (eg. Python Zope Plone).�Dependency injection is a work around to still allow it in a limited manner by passing in its dependency objects rather than instantiating within, or as part of the class.�Of course the alternative to this monolithic class and global state approach is that the dependencies should not all be bundled into classes at all, whether by injection or other means.�Instead services should be decoupled into microservices that are not directly instantiated for use and have asynchronous and retry bindings that deconstruct the monolith.�Having said all that, Go certainly allows type instances to be used to initialize a struct via a New method.�It also has embedded types. If you choose to you can use New to replicate the dependency injection work around for dealing with using the standard monolithic class anti-pattern. But I agree the word ‘Proper’ should not be applied to it.
Package management in Java was such a mess it requires Maven as a 3rd party tool outside the core, to make managing huge Java dependency stacks possible and building Java monoliths viable. If you have ever had to manually tinker with the nested XML dependency stack of a legacy Java app. Maven only seems great because it can get it to work. But it is a fix for a broken feature of the language. Go editing of the go.mod with requires or other hacks is also sometimes required but it is simple single URL lines and the auto-rewrite of the build tools shows you what it is actually going to use. … rant on!
This is possibly an issue in that it is difficult to patch in a fix for a sub module of a 3rd party package. But the only time we have needed this it was to address a general use case, so we could contribute it back to the original library. If that library’s maintainers are not responsive to fixes, simple, stop using it.
Ha Ha … yeah because always getting errors buried in pages of cruft is really helpful.�Golang can do as big a stack trace as the next guy, just turn them on with tools such as runtime/debug
Yes true it runs code no faster than Java once both are running. But Java takes way longer to start up and it loads a way more into memory. So it may be as fast an efficient for CPU, but effectively in a micro service environment of rapidly scaling services, it is way less performant and more resource hungry, so costly to use.
Large monolithic applications are difficult to maintain. The fact that Java encourages services to be written that way, means you have monolithic applications that are easier to maintain in Java. But you don’t write them like that in Go (ideally not in any language these days). You compose them from microservices and then the individual component maintenance is much much simpler. However it does mean that you need the orchestration and release management tools in place to ensure that the full composed service as a whole is also easy to maintain. WIthout the k8s ecosystem or equivalent it can be easier to go with bare metal monoliths.

8 of 9

“Why hasn’t it Got ______ “ wingers

No function overloading
Standard library isn’t extensive enough
Lack of generics
No Sum types (only just added to Java so more a Kotlin / Rust winger)
No immutable types (Java / Python winge)

Function overloading is really a hack that can make things harder to debug. The only proper usage is in a tightly controlled form for functional inheritance. Since Go doesn’t like OOP inheritance, due to the issues it can lead to, its hardly going to think its a good idea for functions either.
Go is designed to be a small footprint. Only the fattest language in the land, Java, would think that having an enormous core library + vm + memory hog behaviour is a good thing
Well its got generics now, due to the wingers. Do I ever use them? No. If I have a job that requires things that vary greatly or dynamically in their types … Guess what I use a dynamically typed language. �If you have a use case where static typing is best suited, and what that type safe contractual element to the code because it reduces maintenance at a complex scale. Then breaking all those reasons now and again with generics seems highly questionable. Why not use metaprogramming (like all unit test mocking does in Go) or reflection. �An example is we could deal with variant JSON payloads from third party webhooks by using Generics. But it is overkill. We can instead just do partial unmarshalling to standard base types - eg to MapOfMaps or ListOfMaps and then check and get the data required.
Sum types classic example is ip4 || ip6 - I believe they are useful, but not enough demand so far.
There are no immutable types because there are direct pointers and references to do this. It could be argued they should be removed and immutables added. But they are so core in Go, I think it is unlikely

9 of 9

Real issues? … discuss or even RANT!

Error handling embedded in functional code
Explicit passing by value or by pointer is less obvious to use than immutable types + use of nil + cases of no warning of uninitialized variables by the compiler�-> null pointer exceptions all day long (nil pointer dereference errors)
Multivalue Assignment hides already instantiated values�-> lost assignment so empty variable �ie errors of new same named temporary scoped variable having value
Not proper OOP … instead structs use�- Interfaces only implementable via implicit duck typing�- Type embedding - and its own complexities - rather than inheritance

Having to handle all errors as part of the functional code is a pain in the arse, why can’t we just ‘try except pass’ and move on. �Because by doing so it forces errors to be considered and handled correctly as the code is written, rather than just dumped into a bucket marked error handling … will sort it out later.�But It makes the code ugly - OK you got me, I agree!
This is a big source of debugging / time wasted. Ideally we should be expert enough to understand why we are passing some variables by value and trace their passage in the code. Rather than rely on wrapping everything up as pass by reference but with immutable types to simulate by value. But actually having more control in Go than in Java or Python over this, is not a good thing in my view. Too few developers are experts at knowing when or why to use either.
This kind of problem is fixable by adopting an explicit standard ie. all vars must be instantiated as such, ban use of :=�But in reality I think that is overkill. All though it is an easy mistake to make, it is also an easy one to fix and it is soon one that you rarely make.
The big OOP debate …

My stories from the battlefield of zope/plone huge multiple inheritance nested class hierarchies that used XML explicit declaration for interfaces etc.�Note that for Go embedded types do allow function overloading to an extent.