The reasons why Golang is a bad language, according to my friend.

why-go-bad.md

Written by @trgwii, not me:

Why Go is bad?

"If Go wasn't made by Google, what would be bad about it?" Stafn asked.

And this is the response from Thomas:

1. uncomposable error handling, this is like being back to:

function foo(x, errback) {
  bar(x, function (err, y) {
    if (err) return errback(err, null);
    baz(y, function (err, z) {
      if (err) return errback(err, null);
      qux(z, errback);
    });
  });
});

2. nil-initialization by default: nil is not always a valid program state, if anything this is a perversion of ZII

3. Not allowing default field values for structs: EVERY time you declare a struct, Go will re-zero it, if the type could just have default values, Go could generate code to set those instead of zeroes no problem, no extra cost.

4. Allowing uninitialized struct fields during initialization: ANY struct can be initialized with {}, omitting all values, no matter what you do, you need linters to fix this externally, imagine being able to initialize any TS interface with {}!

5. Go has like 2-3 meta-languages that exist within Go source files, among them build flags that encode boolean logic based on the build target in comments like //go:build +windows|linux and such, and also string attributes on struct fields, that tell things like json libraries how to serialize

6. Capitalization for public, this is the only reason string attributes are even needed in previous point

7. date API using a hardcoded fixed date string for formatting (meaning you don't say "YYYY" to format as 4-digit year, you say "2007" ("2008" does not work))

8. all pointers can be nil, there is no enforced / encouraged checking / unwrapping. I don't think I have to reiterate nil mistakes of past languages

9. all declarations within all files within the same folder level are exposed to eachother, public and private, public just means package-public, there is no file-private

10. defer is per-function for some dumb reason, which means defer has to allocate memory, meaning that deferring a file close can actually FAIL at storing the function to run!

11. Community is horrible, if you actually try to write highly performant code at the cost of readability, people won't accept your PR's, probably partly because Go's original goal is making it easy for low-skilled developers to write decently-performing applications, so the people that are attracted to Go are very concerned with it being understandable rather than fast

12. Generics are severely limited in that you can't really have return types conditioned on a generic input type, and sometimes they'll compile into dynamic dispatch, and you overall have very little control over and capability using them.

13. lack of unions and iterfaces encourage OOP-style dynamic dispatch and pointer-chasing, which is especially bad in a gc language where more heap objects means more tax on gc pause times

14. named return values are horrible for readability, I don't know why Go and Nim adopted this

15. Go fmt makes horrible decisions that further increase the friction created by uncomposable errors, turning for example this:

if err != nil { return nil, err }

into:

if err != nil {
  return nil, err
}

I think I can do maybe one more but I think starting to get into nitpick territory. I'm sure I forgot something major though, like a third meta-language. Oh yeah!:

16. Go has another OS-dependent build gotcha following build flags from 5., which is that files named *_windows.go or *_darwin.go are only included as part of the build on Windows and macOS respectively, I am not aware of any equivalents for the other OS targets