Go is a great programming language

You are completely right. As a language, Go totally sucks in comparison with other "modern" languages but I think no other "modern" language beats Go when you look for them as tools. Go is a "get things done" kind of language that imposes a lot of constrains on what you can do and how you can do and this limits how developers can express themselves, and it makes Go sucks as a language but these exact constrains make Go excel as a engineering tool because Go code is easy enough to read and understand so it makes your team move fast without break things, fast compilation, fast executions, easy in hardware resources.

Definitely a great engineering tool.

I don’t think Go is considered uncool - if anything it’s the opposite. Probably fair to say that Go is “cool” for hackers and CTOs but “less cool” for formal computer scientists since its type system is limited (and even then goroutines are interesting as first-class construct). But I like Scheme, F#, and Idris, so don’t take my word for it :)

It is like Python in that it is modern, has a rich set of good libraries to do stuff, a simple method of codes reuse (interfaces rather than dynamic duck typing). You have first class functions so you can write cool call back based Jason transformers or the like. Ten liner Python reformatter is twenty in Go. Still clever and way faster and runs on sixteen or 32 cores with no work, assuming you design the program with the data flow in mind.

I have not written many web services, just one gRPC thing which was the typically slow first use of a new framework couple of days work. Mostly I write network shimmies, eg syslog to Kafka or NAT to squid, or else S3 bucket editing utilities.

If it fits neatly into the built-in data structures or smells quite systemsy and C-like, it's probably fairly easy in Go.

String and array manipulation are similarly painful to C. The lack of generics can be a massive pain in the neck, meaning you end up copy/pasting things, and other people's code doesn't tend to be very easily extensible without actually editing it to add the appropriate interfaces or whatever. The lack of OO is sometimes fine, sometimes not. It's really not a very expressive language. (I appreciate that's a rather fluffy/vague thing to say, but I feel it's true.)

On the other hand, you can cross-compile stuff trivially, you get nice self-contained binaries, it's generally sufficiently performant, and it's simple in the same kind of way C is, only with a garbage collector and easier threading (goroutines are pretty nice).

There's no more ceremony really compared to something like Python+Flask, but the business logic you end up running behind your web API calls _may_ be a bit more verbose and feel clunkier. Or if you're lucky it may not. It's very much dependent on what exactly you're doing.

This is a thinking error I see extremely frequently from golang proponents, and it has never made any sense to me. If it were true, it would mean that forth would be a great programming language to work in to keep complexity low - after all it is an even lower complexity language.

Having an, as I'll rephrase it, anaemic language really just means that people will either limit the scope of what they write in it to low complexity things, or, more frequently in my experience, will simply not bother handling the potentially complex details of what they're trying to do, because it's simply too painful and laborious. Corner cases don't get handled (can you really justify the extra 200 lines to handle that case?), user-facing edges don't get smoothed off (can you really justify the extra 200 lines to be able to handle float inputs to that option?), things generally just get dropped on the floor. And I don't blame people - I get to the end of a day and the idea of having to write yet another for-loop makes me just want to go home instead.

The hair-shirt philosophy of golang is not one I subscribe to.

I think the word "simplicity" needs some quantification, because I think often people mean it's easy for beginners = simple. And that doesn't ring true for my definition of simple.

What I'm more interested in where it is "simple", is that it allows logic that doesn't need to be entangled to remain cleanly seperated so that changes to one need not require you knowing about any other parts of it, and are not at risk of breaking anything else.

And similarly, that if I were to build something with inherent complexity the language would add minimal additional complexity above it.

Does Go meet that definition of simple?

The thing that annoys me about exceptions is that they can be slower that you'd think, make safety analysis really hard (i.e. regular control flow isn't too bad, exceptional control flow can be weird), and are a pain to implement. And with Go I don't think of those things as being a priority.

If you prefer Go, and are on a Java team, you'll want to convince others that Go is far superior, and vice versa.