Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stunned by Go

how-bazaar.blogspot.co.nz

Post reply on HN
Print view View original

51–60 of 115 posts

Re: Stunned by Go

#51

Post by [deleted] »

epidemian wrote: post #20
tikhonj wrote: post #5

Wow, this is pretty unfortunate. Also a very good example of why so many people maintain that Go is not nearly as statically typed as languages like Haskell or OCaml: casting (essentially subverting the type system) is very common, and limits most of the type system's advantages. In large part this is because Go's type system is not very expressive. I would just like to point out that OCaml did the same things as Go…

Thanks for the informative comment. > So it would automatically realize that the function called the close method, and infer the appropriate type. So, if i understand this correctly, OCaml would infer that the function takes "an object with write() and close() methods" because it uses both methods in its definition. That's reasonable. But wouldn't that prevent it from accepting objects that don't have a close() metho…

[deleted]

Re: Stunned by Go

#52

Post by pcwalton »

cmccabe wrote: post #49

Supporting typecasting is hardly earth-shattering. Pretty much every statically typed programming language in actual use supports typecasts. That includes Scala, Java, C++, C, C#, Pascal, Algol, and even Ada. This title should be "stunned by shitty poorly documented library function" not "stunned by Go." There are a few languages out there that don't support typecasting. I think SML was one, for example. But they mad…

> There are a few languages out there that don't support typecasting. I think SML was one, for example.

Haskell too, unless you explicitly opt in with Data.Typeable.

It's arguably true in a certainly commonly-used subset of C++ as well: this type of typecast doesn't work in C++ unless you use dynamic_cast or another RTTI system (like COM). dynamic_cast only works on classes with a vtable. Many C++ projects don't use any form of RTTI. (Note that the Go code does not assert that the Reader is a ReadClose; rather it depends on RTTI to determine whether the reader is a ReadClose.)

Re: Stunned by Go

#53

Post by dbaupp »

cmccabe wrote: post #49

Supporting typecasting is hardly earth-shattering. Pretty much every statically typed programming language in actual use supports typecasts. That includes Scala, Java, C++, C, C#, Pascal, Algol, and even Ada. This title should be "stunned by shitty poorly documented library function" not "stunned by Go." There are a few languages out there that don't support typecasting. I think SML was one, for example. But they mad…

> Supporting typecasting is hardly earth-shattering

I think the problem is the standard library using it extensively, apparently without doing it properly. As an example, C++ has casting but the STL doesn't need to use it (much) because it has generics in the form of templates.

Re: Stunned by Go

#54

Post by dragonwriter »

jeremyjh wrote: post #25
tux21b wrote: post #21

Earlier quoted context omitted.

Yes, Roger Peppe, one of the Go contributors, had exactly the same issue, but luckily Brad and Russ, two core devs, were able to solve the mystery immediately and updated the documentation. It's now quite funny to read a blog post from someone completely different (Tim Penhey) who had encountered and solved the same issue with exactly the same usecase on the very same day, complaining about Go without even mentioning…

Documenting this does not solve the problem.

Its solves the problem that side effects that are not expected from the documentation of the behavior of the function are produced.

It doesn't solve the "Go interface types specify minimum functionality that must be satisfied at compile time but do not limit the methods that can be called on an object received through the interface type at runtime" problem, but then, that's a fairly fundamental Go design decision, not a problem. (Especially in the context of Go 1.x, which has a no-backward-incompatible-changes commitment.)

Re: Stunned by Go

#56

Post by frou_dh »

enneff wrote: post #38
rjempson wrote: post #35

I am just wondering whether you can write your own wrapper class that implements (exposes) the read method and doesn't expose a close method (or expose a close method that does nothing) and pass that in? I am not suggesting this is a good solution, just curious.

Yes, easily: var rc io.ReadCloser // a file, whatever readerOnly := struct{io.Reader}{rc} // only a Reader

That's cool. The io.Reader is an unnamed field, so its method is effectively pushed to the surface of the wrapping struct instead of needing to be explicitly forwarded to.

Re: Stunned by Go

#57

Post by marshray »

MatthewPhillips wrote: post #55
marshray wrote: post #44

Earlier quoted context omitted.

There's nothing about OOP that requires weak typing.

I was referring to the fact that this function mutates the state of one of its arguments.

But so does Read(), right?

Even in Haskell I'd be calling the HTTP thingy in the context of the IO monad.

Re: Stunned by Go

#58

Post by drbawb »

tikhonj wrote: post #5

Wow, this is pretty unfortunate. Also a very good example of why so many people maintain that Go is not nearly as statically typed as languages like Haskell or OCaml: casting (essentially subverting the type system) is very common, and limits most of the type system's advantages. In large part this is because Go's type system is not very expressive. I would just like to point out that OCaml did the same things as Go…

I'm not sure if this is what you're talking about, but if you want to see an example of "runtime casting and duck typing" in Go, have a look at my torrent tracker project:

https://github.com/drbawb/babou/blob/master/app/filters/flas...

What I've linked to is a filter that gets put in front of a controller. -- To keep some modicum of type-safety while making use of interfaces, I've added these TestContext() methods to my interface.

Basically, when a controller is registered with one of these chains, the entire chain is checked to make sure that its dependencies are satisfied. (For example, this "flash" filter requires the "session" chain, because it uses session storage for the message being displayed to the user.)

The controller has a similar test; and these runtime penalties are only incurred once when the route is registered. So the app will panic immediately if the types needed for the chain to work aren't present.

It actually works out quite nicely: but you _need_ to write these tests or it falls flat on its face. -- I like to approach it as a form of test-driven development whenever I add a new filter or controller.

Re: Stunned by Go

#59

Post by tel »

cmccabe wrote: post #49

Supporting typecasting is hardly earth-shattering. Pretty much every statically typed programming language in actual use supports typecasts. That includes Scala, Java, C++, C, C#, Pascal, Algol, and even Ada. This title should be "stunned by shitty poorly documented library function" not "stunned by Go." There are a few languages out there that don't support typecasting. I think SML was one, for example. But they mad…

I happily use a coercion-free language every day: Haskell. I don't miss coercion at all. Being able to trust the type contracts that each function portrays is an incredibly important part of the confidence that Haskell gives a developer, team, or leader.

Re: Stunned by Go

#60

Post by usea »

dragonwriter wrote: post #48
usea wrote: post #43

Earlier quoted context omitted.

Go doesn't support overloading. Method dispatch is done by name only. http://golang.org/doc/faq#overloading

But interface satisfaction is by signature, not name, and that is what is being discussed, not method dispatch.

Sorry, I didn't mean to conflate the two. Thanks for the clarification.
Post reply on HN