[CameronNemo]

I am not sure how you refute anything the above poster said. They did not mention performance once (cough Rust cough) and that seems to be most of your point. You did not even say why go is so good for developer productivity... the poster made many points that could be used to argue that go does not promote developer productivity.

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

[nif2ee]

He's an employer, and like I said below it's not surprise that all employers and managers who rarely write any code defend Golang whenever the debate shows up. The language features barely have anything to do with the language itself (easy to pickup -> bigger pool of developers and lower average paychecks/dev, acceptable performance and memory usage and fast compilation times -> better AWS bills compared to Ruby/Python/Java, abundance of support for many cloud and distrubted stuff (e.g. k8s go client, envoy, cloud vendor sdks, etc...)

[wbond]

The data I’ve seen actually suggests Go developers are paid on average better than most other stacks: https://insights.stackoverflow.com/survey/2019#top-paying-te....

[nif2ee]

I am not sure whether these statistic reflect anything on the real world, but even if true this is due to the nature of applications in which Go are used e.g. distributed systems, cloud native, etc... and its concentration in the bay area maybe