[sacado2]

> the poster made many points that could be used to argue that go does not promote developer productivity.

I think go promotes maintainability rather than developer productivity. IMO, go authors favored ease of code reading to the expense of code writers. That being said...

> no option types aka nil access, no enforcement of error checking aka no result types, no enums, no conditional compilation, no iterators, no immutables, etc...

No enforcement of error is not true, you have to explicitely ignore an error if you want to. You have almost the same problem with rust, where you can unwrap things that can fail, thus explicitely ignoring potential errors (granted, the program will then panic).

No conditional compilation is not true either, you can, eg, put at the top of your file build tags:

   // +build !linux

This file won't be compiled on linux (you supposedly have another version of that file for linux systems).

No immutables: can be a problem, const is very limited indeed in go.

Nil access, yes, although contrarily to C/C++, you can't dereference nil without having the program panic. AFAICT I never had them happen in production, when I have a panic it's because of an off-by-one error in a slice, usually (but then I'd have the same problem with `safe` languages like rust).

I'd be glad to have enums. Go's workaround is safer than C's enums, but not by much.

[apta]

> I think go promotes maintainability rather than developer productivity.

It seems to promote verbosity just for the sake of so called "simplicity". It's simple (almost dumb) at the language level, which just pushes complexity elsewhere.

This is just a statement that I find some people repeat without any substantiation whatsoever.

> you have to explicitely ignore an error if you want to

    err := foo()
    ...
    err = bar()
    if err != nil { panic(err) }

The first error was unintentionally discarded. I've seen this happen in actual code bases.

[sacado2]

> It seems to promote verbosity just for the sake of so called "simplicity".

I don't think simplicity is the goal, I think simplicity is a mean to an end, and that end is readability. I remember reading some C++ code I didn't write, and I couldn't understand where the bug was coming from. Turns out the developer had redefined the () operator (or something like that) so that it behaved quite the same as expected, except in a few corner cases.

That's the kind of bug hunt go preserves you from, but verbosity is the price you have to pay.

> The first error was unintentionally discarded. I've seen this happen in actual code bases.

You're right, and AFAIK linters don't catch these.