yinyunqiao/why go and why not go

## why go and why not go

Why Go?
省略溢美之词若干 :) ....

Why not Go?

There are a few things about Go that I'm not super happy about, and that tend to bite me from time to time.

First, you need to "know" whether the variable you are dealing with is an interface or a struct. Structs can implement interfaces, of course, so in general you tend to treat these as the same thing. But when you're dealing with a struct, you might be passing by reference, in which the type is *myStruct, or you might be passing by value, in which the type is just myStruct. If, on the other hand, the thing you're dealing with is "just" an interface, you never have a pointer to it -- an interface is a pointer in some sense. It can get confusing when you're looking at code that is passing things around without the * to remember that it might actually "be a pointer" if it's an interface rather than a struct.

Go's type inference makes for lean code, but requires you to dig a little to figure out what the type of a given variable is if it's not explicit. So given code like:
foo, bar := someFunc(baz)
You'd really like to know what foo and bar actually are, in case you want to add some new code to operate on them. If I could get out of the 1970s and use an editor other than vi, maybe I would get some help from an IDE in this regard, but I staunchly refuse to edit code with any tool that requires using a mouse.

这第一条批评有点无关痛痒，略过

Finally, Go's liberal use of interfaces allows a struct to implement an interface "by accident". You never have to explicitly declare that a given struct implements a particular interface, although it's good coding style to mention this in the comments. The problem with this is that it can be difficult to tell when you are reading a given segment of code whether the developer intended for their struct to implement the interface that they appear to be projecting onto it.

具体结构代码可能会"意外"地实现了某接口，而这基本上是无可避免的。好的代码风格就是如果设计上本就打算实现某接口，那么就用注释，文档，断言，测试什么的来保证一下。否则单纯从代码逻辑上看，无法确定。

Also, if you want to refactor an interface, you have to go find all of its (undeclared) implementations more or less by hand.

如果需要重构某接口，增减方法，改名之类，那就智能人肉去寻找那些本就打算实现这个接口的那些struct代码了，当然文档，测试，go编译器可能会让这个人肉的过程不是那么痛苦。

Most of all I find coding in Go really, really fun. This is a bad thing,
嘿嘿，欲扬先抑，golang高级粉 :)
 since we all know that "real" programming is supposed to be a grueling, painful exercise of fighting with the compiler and tools. So programming in Go is making me soft. One day I'll find myself in the octagon ring with a bunch of sweaty, muscular C++ programmers bare-knuckling it out to the death, and I just know they're going to mop the floor with me. That's OK, until then I'll just keep on cuddling my stuffed gopher and running gofmt to auto-intent my code.

	Why Go?
	省略溢美之词若干 :) ....

	Why not Go?

	There are a few things about Go that I'm not super happy about, and that tend to bite me from time to time.

	First, you need to "know" whether the variable you are dealing with is an interface or a struct. Structs can implement interfaces, of course, so in general you tend to treat these as the same thing. But when you're dealing with a struct, you might be passing by reference, in which the type is myStruct, or you might be passing by value, in which the type is just myStruct. If, on the other hand, the thing you're dealing with is "just" an interface, you never have a pointer to it -- an interface is a pointer in some sense. It can get confusing when you're looking at code that is passing things around without the to remember that it might actually "be a pointer" if it's an interface rather than a struct.

	Go's type inference makes for lean code, but requires you to dig a little to figure out what the type of a given variable is if it's not explicit. So given code like:
	foo, bar := someFunc(baz)
	You'd really like to know what foo and bar actually are, in case you want to add some new code to operate on them. If I could get out of the 1970s and use an editor other than vi, maybe I would get some help from an IDE in this regard, but I staunchly refuse to edit code with any tool that requires using a mouse.

	这第一条批评有点无关痛痒，略过

	Finally, Go's liberal use of interfaces allows a struct to implement an interface "by accident". You never have to explicitly declare that a given struct implements a particular interface, although it's good coding style to mention this in the comments. The problem with this is that it can be difficult to tell when you are reading a given segment of code whether the developer intended for their struct to implement the interface that they appear to be projecting onto it.

	具体结构代码可能会"意外"地实现了某接口，而这基本上是无可避免的。好的代码风格就是如果设计上本就打算实现某接口，那么就用注释，文档，断言，测试什么的来保证一下。否则单纯从代码逻辑上看，无法确定。

	Also, if you want to refactor an interface, you have to go find all of its (undeclared) implementations more or less by hand.

	如果需要重构某接口，增减方法，改名之类，那就智能人肉去寻找那些本就打算实现这个接口的那些struct代码了，当然文档，测试，go编译器可能会让这个人肉的过程不是那么痛苦。

	Most of all I find coding in Go really, really fun. This is a bad thing,
	嘿嘿，欲扬先抑，golang高级粉 :)
	since we all know that "real" programming is supposed to be a grueling, painful exercise of fighting with the compiler and tools. So programming in Go is making me soft. One day I'll find myself in the octagon ring with a bunch of sweaty, muscular C++ programmers bare-knuckling it out to the death, and I just know they're going to mop the floor with me. That's OK, until then I'll just keep on cuddling my stuffed gopher and running gofmt to auto-intent my code.