Interface Upgrades in Go • Hacker News Board

Re: Interface Upgrades in Go

#31

Post by Sphax » Mon, Dec 08, 2014, 10:37 AM UTC

rakoo wrote: post #30

Sphax wrote: post #26

Earlier quoted context omitted.

I was looking for the example proxy around http.ResponseWriter the author talked about which is implemented in Goji, I believe it's this code: https://github.com/zenazn/goji/blob/master/graceful/middlewa... I understand it fine except this bit right at the end: var _ http.CloseNotifier = &fancyWriter{} var _ http.Flusher = &fancyWriter{} var _ http.Hijacker = &fancyWriter{} var _ io.ReaderFrom = &fancyWriter{} What's…

The relevant part of Effective Go is here: http://golang.org/doc/effective_go.html#blank_implements It allows you to make sure fancyWriter implements all those interfaces, so that any future refactoring that breaks compatibility breaks at compile time. You know how Go makes interfaces concordance implicit ? Whatever has a Read() method is a io.Reader without asking for it ? This explicitly tells the compiler (and oth…

Thank you, I read the wrong part of effective Go apparently, didn't see this. It's clear now.

Re: Interface Upgrades in Go

#32

Post by dcposch » Mon, Dec 08, 2014, 11:39 AM UTC

ExpiredLink wrote: post #25

dcposch wrote: post #6

The zero-copy IO in Go is so elegant. I think you can really judge a language accurately by checking out its standard library. This is one of my favorite things about Go. By comparison, * The C++ STL. Fast and useful, but the implementation is nearly unreadable due to template soup. Here's one of the simpler parts! https://www.sgi.com/tech/stl/stl_vector.h * PHP. So bad it's basically a strawman. I'll include it beca…

> Java. A bit better. Compare the readability of OpenJDK's ArrayList.java to the STL vector.h, which does essentially the same thing: http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/00cd9dc3c2b5/s... . But of course the Java standard library is immense and has a lot of cruft in it. Really? Java's success is - rightly - attributed to its simple and usable libraries. > To write clean Java you really need to avoid much of…

Yeah, ArrayList is fine. I was saying the code is cleaner than its C++ equivalent.

There are many parts of the Java library to avoid. Some are obsolete and terrible, like CORBA or java serialization. Others are gotchas w weird semantics, like Object.clone(). Others are just bad API design--eg the built in IO libs don't require a Charset argument. The default is the "system default charset", which is apparently still the obsolete MacRoman if you're on OSX.

The most annoying are those shortcomings of the std library that cause extra complexity. For example, the built-in JUL logging framework sucks enough that almost everyone uses log4j or logback instead. But now you have user libraries using incompatible logging frameworks. Enter slf4j, a shim that ties them all together.

In my experiemce, Go is a breath of fresh air.

Re: Interface Upgrades in Go

#33

Post by jerf » Mon, Dec 08, 2014, 2:16 PM UTC

zaphar wrote: post #18

thomasahle wrote: post #11

Earlier quoted context omitted.

For all the comments Go gets on its typesystem, I suppose if rt, ok := dst.(ReaderFrom); ok { return rt.ReadFrom(src) } Isn't the most terrible way anyone has seen pattern matching implemented. At least it is better than Java's instanceof + cast.

For even more similar look to pattern matching look at Go's type switch. switch i.(type) { case OptionalInterface1: // do some extra thing we allow case OptionalInterface2: // do some other extra thing we allow } It's really good when you have a set of mutually exclusive interfaces or types.

You can do a passable impression of sum types that way too: http://www.jerf.org/iri/post/2917

Re: Interface Upgrades in Go

#34

Post by lmm » Mon, Dec 08, 2014, 3:21 PM UTC

dcposch wrote: post #6

The zero-copy IO in Go is so elegant. I think you can really judge a language accurately by checking out its standard library. This is one of my favorite things about Go. By comparison, * The C++ STL. Fast and useful, but the implementation is nearly unreadable due to template soup. Here's one of the simpler parts! https://www.sgi.com/tech/stl/stl_vector.h * PHP. So bad it's basically a strawman. I'll include it beca…

You've missed out a huge sector of programming languages; I'd be more inclined to take your claim of "unique" seriously if you'd included e.g. Haskell or OCaml.

More importantly, it's a massively biased comparison to look at a language from 3 years ago and compare it to those from 20, 30 or 40 years ago. Of course the standard library will be cruftier in an older language. The Idris standard library is beautiful, really state of the art - as you'd expect from a language that's only been written in the last couple of years.

It will be interesting to see what the Go standard library looks like in 20 years' time; I'm betting it will fare less well than Java's, because the workarounds and cruft necessary to avoid breaking changes will be worse in a language without Java's type system. In the meantime, the fair and informative comparison to make is with languages of a similar vintage.

Re: Interface Upgrades in Go

#35

Post by lmm » Mon, Dec 08, 2014, 3:33 PM UTC

skybrian wrote: post #16

I'm wondering what programmers in functional programmers do about this sort of thing? It seems like they have much stronger type constrants; subclassing and upcasting just plain don't work. And if they did work, it would invalidate the sort of proofs that functional programmers like to do.

Usually we have a more powerful type system that means we don't need to. E.g. in something like Go you might have a Reader, whereas in a functional language you might have [A: Reader], i.e. a generic type A for which a Reader typeclass instance exists. This means you don't have to throw away the specific type (ReaderCloseable) to be able to use it as a Reader.

If you really need to cast, most functional languages will still let you - but as you say, it invalidates the proofs so is very much discouraged (e.g. the scalazzi safe subset requires you to not cast).

Re: Interface Upgrades in Go

#36

Post by TeeWEE » Mon, Dec 08, 2014, 3:35 PM UTC

Note that while interface upgrades are very usefull to use, they are not something very new in the programming language world.

In java you could do:

  if (reader instanceOf BufferedReader) {
    // upgrade
    BufferedReader bReader = (BufferedReader) reader;
  }

This is actualy adviced NOT to do, since its really a runtime type check.

In Go its no different, as this article explains. However its still a usefull mechanism sometimes.

Re: Interface Upgrades in Go

#37

Post by dead10ck » Mon, Dec 08, 2014, 4:31 PM UTC

dcposch wrote: post #32

ExpiredLink wrote: post #25

Earlier quoted context omitted.

> Java. A bit better. Compare the readability of OpenJDK's ArrayList.java to the STL vector.h, which does essentially the same thing: http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/00cd9dc3c2b5/s... . But of course the Java standard library is immense and has a lot of cruft in it. Really? Java's success is - rightly - attributed to its simple and usable libraries. > To write clean Java you really need to avoid much of…

Yeah, ArrayList is fine. I was saying the code is cleaner than its C++ equivalent. There are many parts of the Java library to avoid. Some are obsolete and terrible, like CORBA or java serialization. Others are gotchas w weird semantics, like Object.clone(). Others are just bad API design--eg the built in IO libs don't require a Charset argument. The default is the "system default charset", which is apparently still…

Another example of "Wtf were they thinking when they wrote this?" in the Java stdlib is MessageDigest. To build a digester object, you must pass it a string literal to tell it which algorithm to use, and catch a NoSuchAlgorithm exception. Instead of, you know, just using an enum for all supported algorithms.

Re: Interface Upgrades in Go

#38

Post by crypto5 » Mon, Dec 08, 2014, 7:27 PM UTC

dead10ck wrote: post #37

dcposch wrote: post #32

Earlier quoted context omitted.

Yeah, ArrayList is fine. I was saying the code is cleaner than its C++ equivalent. There are many parts of the Java library to avoid. Some are obsolete and terrible, like CORBA or java serialization. Others are gotchas w weird semantics, like Object.clone(). Others are just bad API design--eg the built in IO libs don't require a Charset argument. The default is the "system default charset", which is apparently still…

Another example of "Wtf were they thinking when they wrote this?" in the Java stdlib is MessageDigest. To build a digester object, you must pass it a string literal to tell it which algorithm to use, and catch a NoSuchAlgorithm exception. Instead of, you know, just using an enum for all supported algorithms.

I think standard Java library API doesn't know what algorithms are supported on particular platform, additionally you can implement your own messagedigest.

Re: Interface Upgrades in Go

#39

Post by crypto5 » Mon, Dec 08, 2014, 7:29 PM UTC

dcposch wrote: post #32

ExpiredLink wrote: post #25

Earlier quoted context omitted.

> Java. A bit better. Compare the readability of OpenJDK's ArrayList.java to the STL vector.h, which does essentially the same thing: http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/00cd9dc3c2b5/s... . But of course the Java standard library is immense and has a lot of cruft in it. Really? Java's success is - rightly - attributed to its simple and usable libraries. > To write clean Java you really need to avoid much of…

Yeah, ArrayList is fine. I was saying the code is cleaner than its C++ equivalent. There are many parts of the Java library to avoid. Some are obsolete and terrible, like CORBA or java serialization. Others are gotchas w weird semantics, like Object.clone(). Others are just bad API design--eg the built in IO libs don't require a Charset argument. The default is the "system default charset", which is apparently still…

> In my experiemce, Go is a breath of fresh air.

Let's see where Go will be in 20 years.

Re: Interface Upgrades in Go

#40

Post by AnimalMuppet » Mon, Dec 08, 2014, 8:19 PM UTC

crypto5 wrote: post #38

dead10ck wrote: post #37

Earlier quoted context omitted.

Another example of "Wtf were they thinking when they wrote this?" in the Java stdlib is MessageDigest. To build a digester object, you must pass it a string literal to tell it which algorithm to use, and catch a NoSuchAlgorithm exception. Instead of, you know, just using an enum for all supported algorithms.

I think standard Java library API doesn't know what algorithms are supported on particular platform, additionally you can implement your own messagedigest.

Right - if I understand correctly, it can depend on what crypto packages are installed on your target.