[nif2ee]

Golang is a pretty much messed up language made by short-sighted and very, very, very stubborn designers. If you don't believe me, just look for instance at all the hacky code generation tools made by the Kubernetes guys. But even if generics are there, the language itself is still very lacking to an irritating level (e.g. 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...)

EDIT: HN upvote system has nothing to do with right or wrong or constructing a good discussion, it's based on fanboyism and political correctness. Really sad.

[tschellenbach]

Go has been amazing here at Stream. No way we would be able to power chat and feeds for 500 million end users with such as small team without Go. C++ would be a valid option in terms of raw performance, but the development overhead is just too large. Go hits a beautiful sweet spot between performance and developer productivity.

[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

[highfrequency]

Curious if there’s a reason Java/Kotlin wouldn’t have worked? There are a number of fast, statically typed languages with much less developer overhead than C++.

[pansa2]

Do any of them have comprehensive standard libraries, and compile to small native binaries? Those features, along with performance and support for parallelism, are why I chose Go (for command-line apps).

[petersellers]

Small native binaries don't seem like much of an advantage when writing servers. For command-line apps sure, but it sounds like OP was addressing someone who was writing a server application.

[sacado2]

Small native binaries don't have to warm up when you start / restart a server.

[pjmlp]

Sure they do, they have to warm up the cache and OS data structures, whence why Windows has a pre-fetch service.

[grumpydba]

> Small native binaries don't seem like much of an advantage when writing servers.

However when deploying server binaries it's a substancial advantage. End users like them. Ops like them.

[lostmsu]

End users happily chug along with 300MB Facebook Messenger on their phones.

On server I am deploying 250MB TensorFlow on a _free_ cloud tier.

Not sure what are you talking about.

I also bet Java or .NET would be speedier than Go after warmup.

[pansa2]

The last time I gave these reasons for choosing Go, that post got downvoted as well. But, still no-one can suggest a more appropriate language to use.

I don’t even particularly like Go. It just seems to be the best solution for command-line apps in 2020.

[pjmlp]

Because plenty of managed languages do support AOT compilation to native code, including Java.

[pjmlp]

Yes, since around 2000's when willing to pay for third party SDKs.

Nowadays OpenJDK, OpenJ9 and GraalVM offer AOT for those that aren't willing to pay for such SDKs.

As for small, Go binaries aren't necessarily that small.

[noelwelsh]

With GraalVM you can compile JVM languages to small executables with limited memory consumption. It's fairly new technology but people are using it in production.

[abraxas]

Java can be as fast as Go if you are careful. Unfortunately idiomatic Java isn't terribly fast because of the pointer chasing behaviour in its collections. The only way to avoid the issue is to work primarily with arrays of basic numeric types. If you sort a large vector<Point3d> in C++ it will be an order of magnitude faster than sorting a similar looking ArrayList<Point3d> on Java because the C++ version stores and allocates these tiny objects in a contiguous memory block.

[LessDmesg]

Java is also going to take a ton more memory.

[pjmlp]

Java doesn't need the trick to allocate useless GB to force the GC to behave, like Twich and others have reported about.

I also bet that Java value types will be available in the language earlier than any Go compiler with generics support.

https://jdk.java.net/valhalla/

[nif2ee]

I would have said so as long as I am the employer and not the one who actually work with the language.

[gen220]

FWIW, I’m a happy Go user who agrees with the direction of your misgivings, if not completely the magnitude.

There is a lot of hacky code in the code generation space, which is why I think the Go team continues to chase generics rather than give it up completely.

A lack of optional types is IMO a wart, that’s tapered over with nil and reflection, but would have benefitted from being a first class piece of the language. I like to imagine this finds its way into Go 2, but I’m not very hopeful.

The rest of your items I view as very nice things that I don’t particularly miss. They’re quirks that are reflective of a minimalist design. At least, that’s the excuse I make.

Result types are interesting and valuable, but add a layer of complexity to a program’s legibility that is understandably desirable to omit, especially when the idiom of returning an error type is so culturally ingrained.

I miss immutables and “modern” iterators, but I can personally live without them. Conditional compilation is kind of antithetical to Go’s design and I don’t miss it too much.

I think most Gophers who have been around the language a while would agree with most of what we’ve said, at least the ones I know.

[jlouis]

Go's strength is not the language.

But there are so much more to an ecosystem than the language itself. People pick Go, despite its language shortcomings. That should be telling to a lot of other ecosystems out there.

Also, the niche it carved out has no other language that fits equally well, I think.

[Kaze404]

Can you expand on what those are? The ecosystem was the worst part of using Go when I had to, specifically because every tool I vsme across I had to double check if it was compatible with Go modules (and half the time they weren't).

[nimmer]

Spot on!

> HN upvote system has nothing to do with right or wrong or constructing a good discussion

Spot on again. You are probably getting a hundred downvotes :(