Another reason I've heard for avoiding getFoo() is that on certain typefaces the lower-case "g" and "s" look similar enough that folks with bad vision can confuse them[1]. Thus foo() and setFoo() are clearer than getFoo() and setFoo().
[1] Given enough time in front of a monitor, we all get bad vision eventually ;-)
The type system is very mediocre. Support for generic programming is awful. What kind of language idiomatically involves casting to the top type? That would be like if Java idiomatically involved casting to Object, or C++ idiomatically involved casting to void*, just to get any sort of genericism. Look at almost any big Go project; the abundance of {}interface typed variables is alarming
And then how about language extensibility? Go relies heavily on built-in keywords, like range and make(). You want to range over a tree or a linked list? Too bad. You can only use built-in types. Or maybe you can wrap your data structure in a chan and range over that. Goodbye performance and simplicity.
Go is not a bad language. I use it on a number of web projects, and it works very well. But Go is not, by any metric I can think of, an "amazing" language. At best, it is a decent language with lots of corporate support, a good standard library, and some good tools like golint, go get, and go fmt.
> Look at almost any big Go project; the abundance of {}interface typed variables is alarming
This statement seems weird to me, so I checked Camlistore (the biggest Go project on my machine). In 65621 LoC there are 306 mentions of interface{}. And Brad does tend to do "clever" things that I probably wouldn't do, so I honestly expected the number to be a lot higher.
wyager is right, empty interfaces in Go are exactly that - a type (set) which every value is a member of, search for Go/interface{}: http://en.wikipedia.org/wiki/Top_type
"However, several languages have types in the second regard above (e.g. void * in C++, id in Objective-C, interface{} in Go), static types whose variables can accept any object value, but which do not reflect real runtime types that an object can have in the type system, so are not top types in the first regard."
I don't know what your definition of "amazing" language is, then, but a decent language with corporate support, a good standard library and good tools....is...well...pretty darn "amazing" in my book.
It maybe doesn't tickle me on an intellectual level, the way Haskell or Clojure do, sure, but for getting real work done, I'd choose it any day over those two.
Other "exciting" languages that play in the same field as Go are perhaps Rust and D, but neither of those have the same corporate/community support, tools, eco-system, etc.
>but a decent language with corporate support, a good standard library and good tools....is...well...pretty darn "amazing" in my book.
This also describes Java in 1997. I wouldn't call that an amazing language either.
>Other "exciting" languages that play in the same field as Go are perhaps Rust and D, but neither of those have the same corporate/community support, tools, eco-system, etc.
I don't know enough about D to speak about it, but at least Rust has a good type system (based on hindley-milner), support for generic programming, pattern matching, extensibility, etc. I'd personally call Rust "well-designed".
I find Clojure to be a very pragmatic language that excels at getting real work done and also happens to be interesting intellectually. On the other hand, your ability to quickly get stuff done in Clojure depends on a fairly radical change in your approach problem solving (functionally, and without mutation). Until that happens most people will find golang a much simpler, more intuitive language.
"It maybe doesn't tickle me on an intellectual level, the way Haskell or Clojure do, sure, but for getting real work done, I'd choose it any day over those two."
Agreed. I'd suggest perfect for the world's dark matter devs.
> I don't know what your definition of "amazing" language is, then, but a decent language with corporate support, a good standard library and good tools....is...well...pretty darn "amazing" in my book.
That's amazing tooling, something which can be had even if the language itself is just decent.
I'm not trying to be pedantic; I think the distinction matters.
I'd agree that Go's language syntax and symantics are very simple at this point. I'm really hoping they improve some of these simple use cases with Go2 whenever that comes about.
What I really like is the whole toolchain that comes with it. Fast compile times, cross-compiling, static binaries for easy deployment, gofmt, godoc, gocode, etc.
> What I really like is the whole toolchain that comes with it. Fast compile times, cross-compiling, static binaries for easy deployment, gofmt, godoc, gocode, etc.
If it also had an OS coded in it, it would be called Oberon (1992).
The name Oberon would be easier to google too. An alarming number of false positives taught me to search for "golang" instead. A small baseline level of alarm is good when you are programming in go for obvious reasons, including {}interface etc.
For me, go is quite amazing, because when I write something and it compiles, in 90%+ of the cases it does exactly what I wanted it to do. Something that I only achieve in python after using it for at least 5 years and I have only used Go for the last year or so.
Nice post Matt! I would love to see more of these eyewitness accounts of refactoring in the go community. Maybe a refactoring video should be in the works ;)
Thanks joe, I realized that the best way to learn is to refactor with one or more people. Hopefully, this summary of a quick refactoring will help others too.
To show that we don't use the value read from the channel, but someone in my team pointed that, that this isn't very idiomatic and mainly a way to explain what the code does to someone who doesn't know Go.
