Hacker News Reader

Comment by 4ad | Hacker News Reader

> I also, apparently, don’t understand Go’s pointers (C pointers I understand fine). I’ve literally had cases where just dropping a * in front of something has made it magically work (but it compiled without one). Why the heck is Go making me care about pointers at all if it is a GC’d language?

Well, sorry, but if that's your level of understanding after one year of Go, I'm furious I wasted time to read your article up to that point.

View on HN

As I understand it, GO makes it so you can use both a pointer or the object itself to access it methods.

And when you define an object method (or I don't know how it's called when you do this:)

func (*string) uppercase(){

    // make uppercase

}

Then by saying you use a pointer means you will modify the value when you do this: mystring.uppercase()

So it's not really pointers, it's more an idea of pointers.

Things get ugly when your code grows. I had cases where I started with passing pointers to structs around directly, but at some decided that having dedicated interfaces would be better.

But as soon as you're talking interface, pointers don't work as expected anymore, because Go (at least that's how I'm explaining it in my head) passes magic interface values to functions. So you can't just change `func foo(s MyStruct)` to `func foo(s MyInterface)`, but rather you probably want `func foo(s MyInterface)`. Even though you are still explicitely passing a pointer when calling foo() and whatever you're doing with s inside of foo() is working on a pointer -- which your own function declaration doesn't even tell you anymore.

This is one of the things that confuses the hell out of me when using Go.

One of the most unhelpful things about Go's pointer syntax is that it collides with HN's italics syntax. Hence, in your second paragraph, i see declarations which differ only in the slope of the type. Really, does nobody think of this when designing a language?

Are you seriously suggesting language designers should care about every sort of markdown syntax that exists when determining how a language looks syntactically?

Take a step back and think about your statement...

Yes this was agreed on HN a few weeks ago. Maybe you missed the discussion "proposal for all new syntax to be HN markdown compatible"..?

Try adding /s in your head and read again...

For the avoidance of doubt, my comment was intended as a humorous way to point out to the parent that they had got their code snippets mangled, and i am not seriously advocating Markdown-compatibility as a language feature.

I'm curious, though, as to how you could possibly think i was being serious. Do you spend a lot of time interacting with people with insane ideas?

No, it's an unhelpful thing about HN having a terrible partial subset of markdown: ignoring that every other markdown implementation under the sun has more supported markup, all of them provide ways to escape markup characters and inline code sections which ignore markup characters.

I'm on hacker news, so I can't actually tell if you're making a joke or not.

Given an `type IBar interface { Bar() }`, if you implement all your member functions in the form `func (this \*Whatever) Bar() {...}`, then only a pointer-to-Whatever implements IBar, not values of type Whatever. However, since golang can call functions with pointer receivers on values, a member function in the form `func (this Whatever) Bar() {...}` implements IBar on both values and pointers of type Whatever.

See http://play.golang.org/p/ToRh0uK3zw for a demonstration.

Edit: Actually, you can call a function with a value receiver on a pointer value too, so this behavior is inconsistent =/

Reply on news.ycombinator.com