Why compiled Go programs give a warm fuzzy feeling
If you have used Google Go in a real world project/application, you will feel all warm and nice after your code can be compiled and your application runs. It usually runs almost flawlessly - or only requires a few minor tweaks before its ready for production. I have felt it many times while building stuff in Go and never felt similar in other languages. And I always wondered why this happened only with Go.
I think that this feeling comes from the fact that you know unconsciously that the program you wrote is rock solid and fast (usually). How do you know that? Go's toolset and philosophy towards building programs has a lot to contribute to this feeling. Like -
Error Handling: I think this is by far the biggest thing that contributes to the warm fuzzy feeling. Go forces you to handle (or explicitly) ignore the error/edge cases in your code, then and there. It throws a compiler error otherwise. So by the time you reach the point where you can compile the code you know that you have handled all the error cases. The code would not have compiled otherwise.
Gofmt: No more arguing about the best conventions or whether you want the opening brace on the same line or the next one. Gofmt does the job for you and you don't need to worry about it - ever. Its so damn easy to use it as plugin in your favorite editor and run it every time you save a .go file. Everyone's code looks the same, reads the same and feels the same.
Static types: Coming from the world of dynamic languages like Ruby, Python and Javascript, having static types is a god send. You are confident that you are dealing with one type of data structure and that one only. Go's syntax is sufficiently terse (and readable at the same time!) that your program doesn't look too verbose or dense. If you do want variables with "dynamic properties" there is always the interface{} type that you can fall back into.
No Manual Memory Management: Go's memory is managed. Its GC is already performant and is increasing in efficiency as the language/compiler has evolved. I think this gives it a huge leg up from other languages like C++ where memory is managed manually. I want to focus on getting the task done, not think about managing memory.
Unused imports and are circular imports are compiler errors: This is really good since it forces you to keep your overall project structure clean and terse.
There is always an idiomatic way to do things in Go: The Go community and the golang.org website have made it really explicit on what is a good way to write code and what isn't. So when you are going through resources or talking with other people about writing Go code, you will always notice that there is a huge emphasis on writing the things the idiomatic/correct way unless there is a good reason not to. It leads to efficient, readable and clean code. I refer people a lot to the (really well written!) Effective Go page where you can easily understand the best practices of the language.
Although each factor in and itself is not enough, when combined together, Go nudges (rather subtly i might add!), the programmer along the right path towards that warm fuzzy feeling of rainbows and unicorns. ;)