Go, robots and refactoring | Hacker News Reader

Go, robots and refactoring

matt.aimonetti.net

98 pointsmattetti36 comments

I would suggest naming the method "Device" instead of "GetDevice". The word "Get" is almost always redundant.

I totally agree, I found myself refactoring my own code and renaming "Get<>()" functions. I wish I had heard someone say that earlier :)

m.FindRobot("bot name").GetDevice("laser") would read better as m.Robot("bot name").Device("laser")

Agree, but due to my mild OCD, I still keep using Get to pair with Set :)

I also feel that mild nagging feeling, but it passes quickly. The brevity is worth it. :-)

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 ;-)

That's easily solved by just not using typefaces that you can't read in your editor.

>Go aka golang is an amazing language

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.

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.

Then what would you call an "amazing" language.

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.

That sounds simply like strong typing vs dynamic.

> 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.

>there are 306 mentions of {}interface

Would you be happy with a Java project with 306 mentions of Object?

I wouldn't be happy with a Java project with 306 mentions of anything.

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.

>I wouldn't be happy with a Java project with 306 mentions of anything.

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?

Go does not have type inheritance, so there's no such thing as "the top type".

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

Edit: the downvoter cares to explain?

"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."

Do you consider void* the same as Java's Object?

Well, the "all encompassing" type. Or the "variant" type.

306 mentions sound a lot.

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".

>This also describes Java in 1997. I wouldn't call that an amazing language either.

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..

"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.

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 Jeremy, let's book a few hours and do that together.

This is really helpful. I'm getting started with Go now and common idioms and refactoring are useful when moving past the tour and introduction stage.

This is a really helpful article - nice work Matt.

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.

Go looks interesting. Anyone else not a fan of the single character variable names?

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.

In the first version of the post I had

_ = <- 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.

Thanks for sharing this Matt.. really good insight.

Great post really enjoyed it.

Also a big fan of golang, loving the posts by people using it in anger.

Thanks

Reply on news.ycombinator.com