4 ms·
The problem with Go is that you don't grok Go interfaces. EDIT: downvoters, please explain what's wrong with my comment. Go interfaces are quite a novel conce
by 1_player 12y ago
The problem with Go is that you don't grok Go interfaces.
EDIT: downvoters, please explain what's wrong with my comment.
Go interfaces are quite a novel concept, and most developers that jump from language X to Go don't have enough time and experience to understand how they work, and how to design their application around this new model.
Their example of the messaging system/UI application is a straight port of the Rust code, and they lament the fact they have to use interface{} to overcome the lack of object orientation or pattern matching.
func paintingLoop(ch chan interface{}) {
// shorthand for a loop over receiving over
// a channel
for msg := range ch {
switch ch.(type) {
case Quit:
// quit
case DrawLine:
// cast to a drawline message
line := msg.(DrawLine)
// draw `line`
case DrawTriangle:
tri := msg.(DrawTriangle)
// ...
case SetBackground:
bg := msg.(SetBackground)
// ...
default:
// Need a default case in case
// some other type is fed through here.
}
}
}
This is not idiomatic Go. The author here should be leveraging Go interfaces and they wouldn't lose type safety.
type Drawable interface {
Draw()
}
type Line struct {
x1, x2, y1, y2 int
}
func (l *Line) Draw() { ... }
type Circle struct {
cx, cy, radius int
}
func (c *Circle) Draw() { ... }
func paintingLoop(ch chan Drawable) {
for object := range ch {
object.Draw()
}
}
func main() {
ch := make(chan Drawable)
go paintingLoop(ch)
ch <- &Line{x1: 10, y1: 10, x2: 50, y2: 50}
ch <- &Circle{cx: 10, cy: 10, radius: 20}
}
You wouldn't expect Python programmers to try Haskell over a weekend and have enough experience with it to write a blog post about "Thinks I dislike about Haskell", but it seems much to often people play with Go and, when they fail to translate their ideas to this new language, post yet another "rant" on HN about how Go sucks.
Go has its fair share of shortcomings, but try to _learn_ the language before writing yet another misinformed article.
- zalmoxes 12y agoYour example is not idiomatic Go either, the interface should be named Drawer not Drawable.
- jwcrux 12y agoThis is both a blessing and a curse for Go. The language touts itself as being easy to pick up, and has a batteries included stdlib. This allows developers to quickly say "I know Go. Here's what's wrong with Go." since they believe they have learned all there is to know about it. This is good, since that's part of why Go is approachable. However, this has downsides. As you showed, there are succinct features that can make the difference between "this is a bad thing" and elegant code.
- 1_player 12y agoShould the language be cryptic and complex for people to take it a little more seriously? OK, it seems I'm trying hard to defend Go. I like it, I seldom (but do) miss generics, I miss some Haskell/Rust features and wish it were a little less simple. But I don't understand why there are dozens of similar "things about Go" articles posted every week on HN, all repeating the same stuff. The one from Evan Miller was both entertaining and in-depth, but that's the exception.
- egwor 12y agoYou're clearly know a lot about this topic. Not everyone else is quite as up to speed and the article was a rather interesting view from a learner's perspective. No one expected it to be perfect, and it was particularly well considered considering the experience and time the author had had. Our comments are ultimately feedback. We're a community and we want constructive feedback to help each other learn. When giving feedback, just remember to be constructive and consider how your tone could be perceived. I'm sure that you had the best intentions but the undertone of the comment read to me (and many others) as very cutting/attacking.
- zaphar 12y agoThe author is upfront that this article is about first impressions. He freely admits that he is probably not writing idiomatic Go and as a result his first impressions are skewed. That doesn't mean the article isn't interesting or useful though. It's helpful for any language community to see what a new comers first impressions are and then tailor the onramp appropriately in their documentation. You are unneccessarily hard on the author here I think.
- masklinn 12y ago> Go interfaces are quite a novel concept They're not: https://realworldocaml.org/v1/en/html/objects.html#ocaml-objects https://realworldocaml.org/v1/en/html/objects.html#ocaml-obj... > This is not idiomatic Go. The author here should be leveraging Go interfaces and they wouldn't lose type safety. You've conveniently ignored the case of the non-drawing commands. Should they be Drawables with a Draw which does not draw anything? > Go has its fair share of shortcomings, but try to _learn_ the language before writing yet another misinformed article. The OP has been upfront about his limited knowledge of Go, and his rust knowledge coloring his thinking.
- pcwalton 12y ago> You've conveniently ignored the case of the non-drawing commands. Should they be Drawables with a Draw which does not draw anything? In particular, you can't implement Quit using a virtual method, unless you do something like have every function return a boolean to the caller indicating whether it wants to quit (or panic and recover, but that's too awkward for words). You also can't have methods that set local variables in the caller, unless you do something like pass in their addresses to the function, which gets awkward quickly if you have a lot of local variables.
- azth 12y ago> You also can't have methods that set local variables in the caller... How would you do that using ADTs?
- pcwalton 12y agoYou don't use methods, but instead switch on the discriminant of the ADT and take different actions (such as updating local variables). This is pretty related to the so-called expression problem. OO-style methods are good at extensibility, but they're bad at adding extension points (method calls), since you have to update every one and calls are limited in expressive power compared to the body of a switch statement. Functional-style ADTs are bad at extensibility (adding a new type requires updating all pattern matches), but they're good at adding new extension points, since you don't have to touch the data types and pattern matching is powerful. Supporting both styles in a language gives programmers the freedom to choose the best one for the task at hand.
- Manishearth 12y agoThis still has a vtable creation/dispatch overhead in your example (if I wasn't clear, this was my larger concern, not the type switches). It also has troubles with local variables, though they can be solved pretty easily. But point taken. I will try to use this pattern in the future. > Go has its fair share of shortcomings, but try to _learn_ the language before writing yet another misinformed article. I believe I was pretty clear in the article that I didn't know the Go way of doing things and this was about what Go looked like from a Rust point of view. This was not supposed to be a rant, just a post that sort of illustrates the differences between the languages. IMO it actually gives a clearer idea of what Rust is like than it does of Go since the "Rust way" of doing things is clear from the comparisons..
- natrius 12y agoThis great comment would be better without the needless insults. Consider omitting them next time.
- lobster_johnson 12y agoThe author here should be leveraging Go interfaces and they wouldn't lose type safety. This assumes the structs themselves know how to draw. This is usually (not always) an antipattern, because it conflates data with behaviour. I should be able to swap out the drawing implementation without having to change the data. For example, given a circle (cx, cy, radius) I should be able to draw it using SVG or OpenGL. The enum way is not necessarily "unidiomatic Go". Even if you have something that turns data structs into "strategy" objects that know how to render, you need a matching statement, or you need to build something like a "map[Type]Drawer", which is in my opinion less elegant.
- jblow 12y agoYeah, umm, especially in high-end games, the idea of every object "knowing how to draw itself", in the stereotypical OO way, is completely absurd.