Hacker News Reader

Comment by barakm | Hacker News Reader

Not bad, at least a fair look!

One thing that immediately set off my radar (as a Go programmer) is the paintingLoop switch on type.

Yes, sometimes a switch on type is necessary. However, this is not one of those cases.

You want to have a Triangle and Line with a Draw() method and a "Drawable" interface... and then just call into it. The signature of the loop in question then is paintingLoop(ch chan Drawable).

An abuse of naming, but a Quit.Draw() could actually quit, for example. This is just offhand though.

In short, good article, but the Go examples are written with a Rust intuition. Which, I mean, fair enough; I started writing Go with a C++ intuition, with different questionable practices ;)

View on HN

Yeah, that would work, though then I need to worry about all the local variables too (which I didn't use in the example but did need in the actual code). Still, not a major overhead since I can use a context object for that. Anyway, my issue was with the vtable dispatch of interfaces more than with type switches -- using a .Draw method is pretty much the same :)

But yes. It was written with Rust intuition, and whilst I ried to learn the Go way of doing things, I obviously didn't pick up everything :P

Thanks though; I'll try to use this pattern in the future!

I'd love to post a Go-best-practices article on Polyglot Weekly, as a rebuttal. If you or anyone else reading this thread would be interested :)

Glad you pointed this out. Hopefully the original author will make a note of that on his blog because when people run across it they will be given the wrong impression about how this would be handled in Go.

I love how "opinionated" and slim Go's design is. The less variation in code, the better, in my opinion. It might not be as "fun", but frankly I have a lot more fun programming when I don't have to deal with esoteric solutions to problems.

I'm not so fond of editing an already published post, but I'll ask bcoe if we can/should do that and add some clarifications.

Would it be reasonable to create a separate channel for each message type, and switch over all of them in the receiver?

that sounds heavy to me.

Generally using multiple channels and select is good when you have multiple threads sending. When there is a single sender, putting everything in one channel feels better to me.

Dynamic dispatch isn't really a replacement for true pattern matching, as pcwalton explains downthread. Local variables (which would be represented as some sort of scope/context object) are one problem, but so is encapsulation. Why would you make the assumption that (X data) knows how to draw itself? What if you're doing something like handling system events? The only true replacement here would be the visitor pattern—which itself is a PITA for a bunch of reasons.

Reply on news.ycombinator.com