This is by no means a comprehensive list:

* no generics

* null pointers

* no compile time checked enums or sum types

* The golang time package is garbage

* golang interfaces are garbage, can't tag types with an interface without implementing a dummy method and hope that no other type implements it. Can't find what interfaces a type implements without an IDE

* profiling and debugging tools are nothing in front of JVM and .NET tools

* no const/immutablility

* no ternary operator, need to write 6 lines instead of a single line if it existed

* error handling is error prone and verbose

* no default method implementation in interfaces

* unit testing frameworks are sucky and rely on code gen, can't mock arbitrary types, but only by defining an interface

* that unnused variables and imports are compile time errors, makes it very annoying and time consuming to prototype or when debugging

* no private/public/etc modifier. if you want to change the visibility of a type, you need to rename it in all files it's listed in

* no incremental compilation (yes Java compiles faster in large projects where I only modify a handful of files, or even more)

* pervasive use of single letter identifiers in golang code bases

* pervasive use of int, which has a platform dependent size

* pervasive instantiation of structs by calling them structFoo { Field1: field1, Field2: field2, ... FieldN: fieldN }, which makes it easy to miss when a new field gets added. Rust and Zig solve this by making it required to specify all fields and values.

* defer works on the function scope, not the current scope

* defer doesn't handle functions that return errors, meaning many errors are missed

* no struct or file private, only package private

* the global scope is polluted with special functions like len, copy, delete, make, new, append, for no good reason

* golang imports don't support cyclic imports

* golang doesn't allow you to import a a specific function or struct from a package. You have you always qualify anything with the package name, which makes things verbose and awkward.

Thanks for the writing. I had noticed some of the things you wrote but not all (I am not a Go programmer though I keep track of what is happening there). Your post made me look a bit more into 'defer'. I did not expect it to be a source of errors.

No problem. As a side note, the Zig language does a much better job here, especially with defer. It works at the scope level (how it's supposed to be), and they have an `errdefer` construct used to call functions that return errors.

> no incremental compilation

Not true, unless you're using an esoteric definition of "incremental".

> imports don't support cyclic imports

Why on earth would you consider this bad?

The problem that I've ran into with the lack of cyclic imports is that I like to arrange the contents of packages logically. However sometimes in order to do this it would result in a circular dependency between two packages. So rather then getting a logical arrangement we have to refactor it into an artificial package to resolve this depenancy.

Circular imports are always a design error, no "logical" to it.

I will hopefully later today, not able to type much now.