There are a lot of bad things in Go, sure. And some are really annoying, like "goroutine all the things" mantra.
But no matter how I dislike it there is just no other choice today. It all comes down to support, bug fixing, ease to learn and to use, good standard library, built in cross-compilation and a pretty fast one, static binaries, good enough dependency management, reasonable performance and memory usage, especially in comparison to python/perl/ruby, integrated unit testing, code formatting tool, etc. All these things together matter more, than the language itself.
Too bad you can't unlearn functional programming. Or generic programming. Or algebraic datatypes. Or having actual useful datatypes. Or ...
Just the basic thing of sorting a list containing a struct. And the suggested solution by the Go team is a 50 line program. WTF.
They actually claim the err = function(); if err != nil {}. This is the reason I originally left C. And those criticisms really apply to Go as well. Firstly nobody sanely checks those errors, often outright ignoring them. Second when they do, they always just pass the error up (in other words: manually implementing exceptions), or worse, they panic on the error (meaning you cannot trust external libraries won't panic on you, negating the single advantage that leaving out exceptions had). Even if you do check those errors they interrupt the train of thought you have. Imagine someone telling you how to open a door in Go : first, put your hand on the handle. If you don't have a hand then go to the hospital. If there is no hospital near you then go to the car. If there is no car then check for a bike. If the door is locked ... wait what was I doing ?
Thirdly functions that might return a variable or might not ... the official Go team's advice is use a pointer. Sigh. The amount of times I've seen people commit Go code into my program that doesn't check for nil-ness ... Grrrr.
If you don't mind living in the dark ages, then yes, Go is great.
F# has that. With Mono you can produce static binaries. And the F# compiler can also make statically linked assemblies, including the bits it needs from all its dependencies.
Although I'm not sure if there is an F# code formatter tool. Which is made up for by F# being a vastly more capable language.
Yes, some code formatting tools exist (within Visual Studio as part of F# Power Tools, and also I believe standalone in some binary form). However, as a community we're currently a little less dogmatic than Go (for example) about what "correct" formatting is.
Tabs vs. Spaces is decided at the language level (it's spaces or it doesn't work) but other things are often a matter of taste. It doesn't tend to matter too much though because (well written) F# code is expressive almost regardless of minor formatting issues (poorly written code in any language is a comprehensibility mess, regardless of "neatness" or newline consistency!)
