Readability. I never ran into go code I couldn't read.

Native CSP? That's what got my initial interest. The tooling really helped it stick though.

Swift is nowhere outside of mobile space, on server side it's pretty much dead.

Swift and Rust both are known for long build times.

Mostly caused by LLVM.

Other equally expressive languages have multiple implementations, including REPLs, with Go like compilation speeds.

So Swift and Rust just need equally LLVM fat free implementations for the developer loop, leaving the LLVM backend for the blazing execution release builds.

LLVM isn't fast, but there are other slow parts of the process unique to Rust [1].

[1]: http://gistpreview.github.io/?74d799739504232991c49607d5ce74...

Please don't degrade the community and yourself by posting like this, regardless of how strongly you feel about programming languages.

https://news.ycombinator.com/newsguidelines.html

I'm not saying it's a bad thing.

Ok, but it's a bad thing to post like that to HN.

Go has its issues, name a language that doesn't.

For a long time I couldn't stand using it because it's so damn opinionated, but it still hits a sweet spot for me.

I like C a lot because of its simplicity, but hate spending days solving trivial problems.

If you really need C, nothing else will do. But if you're willing to trade some flexibility for convenience, Go lets you make that compromise without dragging along a ton of features that you didn't ask for.

It's a tool, if it works it works.

The overwhelming majority of Go code isn't written at Google, and just a glance at Github will show you that it isn't being used to "jerk off into template engines" or "increase clickthrough rate by 0.1%". This comment contributes nothing to the discussion.

> The overwhelming majority of Go code isn't written at Google

I write go for my day job; I'm quite aware of their process. They control the language's future and new features pretty much single handedly. Also, I'd be very very surprised to find out that the overwhelming majority of code isn't written by google, do you have a stat on that you can quote?

> it isn't being used to"jerk off into template engines".

I'm saying go doesn't do that. You can't build these crazy compile time abstractions in it like you can other languages, and Google doesn't really need it to because they have enough man power to just brute force it. It doesn't want their workforce build abstractions for abstractions sake, and go doesn't really help you do that.

> or "increase clickthrough rate by 0.1%".

It is very much used to do that, I've been told by product and engineering friends at google.

I'm sure developers at Google use it to do that, because that is a problem that Google works on. It is not a problem that Cockroachdb works on, or that Docker works on, or that Hashicorp works on, or that Caddy works on, or that Tailscale works on.