Stunned by Go • Hacker News Board

Re: Stunned by Go

#111

Post by dragonwriter » Thu, Jul 18, 2013, 6:31 PM UTC

axelf wrote: post #110

thirsteh wrote: post #7

Earlier quoted context omitted.

An example: http://golang.org/src/pkg/io/io.go?s=11741:11801#L336 Line 336. io.Copy takes a writer and a reader, but actually asserts whether they implement ReaderFrom/WriterTo, then use their methods, ReadFrom and WriteTo, if they do. (Same thing with the http package checking if the reader implements Closer, and calling Close if it does, though admittedly 'we should be able to call Close' is a much more unsafe assu…

Does Go not provide method overloading? Couldn't they have 3 versions of the copy method?

> Does Go not provide method overloading?

Yes, it does not permit method overloading.

Re: Stunned by Go

#112

Post by GhotiFish » Thu, Jul 18, 2013, 7:10 PM UTC

nknighthb wrote: post #107

GhotiFish wrote: post #106

Even if there is agreement that this is a problem, it strikes me that it can become a problem. The standard library should be exemplary, what do you think would happen in the hands of a developer who's "not as smart as he thinks he is?" Wasn't that part of go's pitch? I never really considered that libraries would go so far as to inspect the types for methods rather than just make those methods a requirement. The fac…

What was part of Go's pitch, exactly? And where did you see it pitched? People outside the Go team have tried to pitch Go as a lot of things, most of them having no relationship to what Go was actually intended to accomplish. The FAQ[1] may be enlightening. Nowhere does it say Go is supposed to be a straightjacket that makes bad programmers into good ones. [1] http://golang.org/doc/faq#What_is_the_purpose_of_the_proj…

You'll have to forgive me, I'm at work right now so I can't pull up the talk Rob Pike did on Go, I think it was 2011.

Around the point where he explained Go was not a language to expand the boundaries of computer science. It's for programmers who "often are not as smart as they think they are"

I'll look it up when I get the chance. That might be later tonight.

Re: Stunned by Go

#113

Post by danudey » Thu, Jul 18, 2013, 7:32 PM UTC

mseepgood wrote: post #91

Locke1689 wrote: post #87

Earlier quoted context omitted.

This is not the same thing. The problem with the Go implementation is essentially that the method is semantically different from the expected method. Closing a stream is semantically different from not closing a stream. It just is. The Go method was just wrong . The problem was not the type introspection. There's nothing wrong with us attempting to do optimization for ICollection`1 or the rest of the collection inter…

> This is not the same thing. The problem with the Go implementation is essentially that the method is semantically different from the expected method. No-one is arguing about the Close() case. However, the io.Copy() case is comparable to the IEnumerable .Count() implementation.

Unless your WriterTo method does something different than the caller assumes it's going to do.

Unless the special functions are predefined by the language (e.g. Python's __str__, __len__, __iter__, etc.) or specified in an interface that the class explicitly inherits from, making assumptions that the language developers and I meant the same thing is careless at best and dangerous at worst.

Re: Stunned by Go

#114

Post by nknighthb » Thu, Jul 18, 2013, 7:33 PM UTC

GhotiFish wrote: post #112

nknighthb wrote: post #107

Earlier quoted context omitted.

What was part of Go's pitch, exactly? And where did you see it pitched? People outside the Go team have tried to pitch Go as a lot of things, most of them having no relationship to what Go was actually intended to accomplish. The FAQ[1] may be enlightening. Nowhere does it say Go is supposed to be a straightjacket that makes bad programmers into good ones. [1] http://golang.org/doc/faq#What_is_the_purpose_of_the_proj…

You'll have to forgive me, I'm at work right now so I can't pull up the talk Rob Pike did on Go, I think it was 2011. Around the point where he explained Go was not a language to expand the boundaries of computer science. It's for programmers who "often are not as smart as they think they are" I'll look it up when I get the chance. That might be later tonight.

I'm reasonably confident you're assigning too much significance to what was probably an offhand remark in a particular context. I just looked at slides from a 2010 talk[1] by Pike which was pretty explicit about what they were doing in this area:

"It's a form of duck typing, but (usually) checkable at compile time. It's also another form of orthogonality."

And this one from Russ Cox in 2010[2]:

"Compiled, statically-typed languages (C, C++, Java) require too much typing and too much typing:

* verbose, lots of repetition

* too much focus on type hierarchy

* types get in the way as much as they help

* compiles take far too long"

A common theme for Go from the beginning has been the balance between type safety and not getting in the way of the programmer. The analogy to duck typing has been a consistent observation throughout Go's public existence. This is incompatible with the sentiment you took from whatever talk you saw.

Go's architects didn't set out to make a Java clone. It's more like Java's evil twin.

[1] http://talks.golang.org/2010/ExpressivenessOfGo-2010.pdf

[2] http://talks.golang.org/2010/go_talk-20100112.html

Re: Stunned by Go

#115

Post by rat87 » Fri, Jul 19, 2013, 8:01 AM UTC

pjmlp wrote: post #84

rat87 wrote: post #81

Earlier quoted context omitted.

(I'm not a c# expert and I may be wrong) IEnumerable really only requires a IEnumerator GetEnumerator() method most of the real "meat" of ienumerable is in the static System.Linq.Enumerable class. You see c# doesn't have multiple inheritence or scala like traits or type classes but it does have a cool compiler hack called Extension methods( http://msdn.microsoft.com/en-us/library/vstudio/bb383977.asp... ). You take a…

This is not a compiler hack, there are quite a few languages out there that support this concept. As for your Scala remark, extension methods in Scala are done via implicits.

I didn't mean hack in a derogatory way, I think its a fairly elegant solution in many ways just that to my knowledge it doesn't really change the static/dynamic type and is just a simple compiler transformation.

I should have mentioned that I know even less about scala then c#. I/m not quite sure how implicits are implemented/optimized but I'm pretty sure you can have inheritence/overiding traits as implicits.