Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"You don't need reflection to break parametricity."

Correct; I cited reflect just because it lets you do anything; i.e., you can get a type you don't understand at all, and reflect can go groveling through the type to see if it can find an embedded type it does understand, or even directly muck about with unrelated struct values, or any other crazy thing. Type switching requires you to be able to name the types you're going to examine in advance; with reflect you can even do horrible things to types that didn't exist when you wrote the code.

But then, the answer is mostly not to do that. Go isn't academically pure, but neither is it full of people writing crazy code like that. And so, technically, you can't use this reasoning in Go... but even so, enough of it is there that I get some mileage out of it. I find my expertise in Haskell transfers in Go in some bizarre and unexpected ways, because while Go doesn't have much, Haskell taught me a lot about exploiting what is there to the maximum I can. Even though by Haskell standards haughty sniff Go is barely even a programming language (well I never!).



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: