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.
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 ;-)
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 ;)
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.
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.
> 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".
"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 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.
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.
36 comments
[ 3.5 ms ] story [ 93.8 ms ] threadm.FindRobot("bot name").GetDevice("laser") would read better as m.Robot("bot name").Device("laser")
[1] Given enough time in front of a monitor, we all get bad vision eventually ;-)
By what standard? I've been very underwhelmed.
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.
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).
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.
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.
Would you be happy with a Java project with 306 mentions of Object?
Go's interface{} and Java's Object not the same thing, nor are they used for the same ends.
Eyeballing the Camlistore code I am not distressed by its use of interface{}. It's fine.
Please expand on this.
>Go's interface{} and Java's Object not the same thing,
Yes, they are. They are both the top type.
>nor are they used for the same ends.
Yes, they are. Did you ever use Java before they added Generics?
Edit: the downvoter cares to explain?
Do you consider void* the same as Java's Object?
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.
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".
You're joking right? I've used Java around 1998 and its standard library wasn't good, "java can't print" was quite true back then..
Agreed. I'd suggest perfect for the world's dark matter devs.
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.
Also, Is there a better way, in terms of clarity, to do this:
<- c
Even with the comment I would think the developer forgot to fill in the first half of that and assume it was a bug.
_ = <- c
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.
Also a big fan of golang, loving the posts by people using it in anger.
Thanks