News for hackers. Stuff that matters.
Re:Go 2 Draft Designs by nemothekid on Tuesday August 28, 2018 @02:55PM (#17861752)
I'd argue that Generics make the language easier for the writer, not the reader which is what he was getting at. What I like about Go is the language is small, so at the expense of some verbosity, that in most cases you write once, its very easy to understand. One thing I dislike about some Java & Scala codebases is the "manual" unwinding you have to do to debug some functionality.
Re:Go 2 Draft Designs by whateveracct on Tuesday August 28, 2018 @03:22PM (#17862009)
This is FUD.

Parametric polymorphic code is not hard to read at all - in fact, it is easier to reason about since it is universally quantified for all types.

Re:Go 2 Draft Designs by chowells on Tuesday August 28, 2018 @04:07PM (#17862401)
Most people don't even know what parametric polymorphism is, let alone have ever used a language that supports it. I find it's basically impossible to explain just how powerful of a tool it is to someone who lacks experience using it.
Re:Go 2 Draft Designs by aikah on Tuesday August 28, 2018 @04:38PM (#17862643)
"append","delete","copy" in Go is parametric polymorphism hardcoded in the compiler. append can be called with many different array types. There is nothing complicated with that.

go can iterate over arrays irregardless of the element type the same way with the same construct using "range", therefore "range" is polymorphic.

The real debate here is should the compiler be "privileged" or should there be API in userland to implement these behavior.

Re:Go 2 Draft Designs by sdegutis on Tuesday August 28, 2018 @04:14PM (#17862445)
> Today it exists in Standard ML, OCaml, F#, Ada, Haskell, Mercury, Visual Prolog, Scala, Julia, and others.

> Java, C#, Visual Basic .NET and Delphi have each introduced "generics" for parametric polymorphism.

https://en.wikipedia.org/wiki/Parametric_polymorphism

Re:Go 2 Draft Designs by chowells on Tuesday August 28, 2018 @06:33PM (#17863536)
A bunch of low-reach languages have true parametric polymorphism. A bunch of common languages have polymorphism that may be parametric or may be bounded by runtime type information checks, and you can't tell the difference from the types.

Neither of those contradict my assertion that most programmers have never done work in a language where the type system can make guarantees that they can trust.

Re:Go 2 Draft Designs by whateveracct on Tuesday August 28, 2018 @08:16PM (#17864082)
This is a very pedantic point
Re:Go 2 Draft Designs by whateveracct on Tuesday August 28, 2018 @04:58PM (#17862822)
The only programmers who haven't used a language with parametric polymorphism are those who have only programmed in C, Go, or dynamic languages at this point.

Outside of Java syntax noise, I really have my doubts that Java's parametric polymorphism is too complicated for the average programmer to understand.

  public static <A> A identity(A a) { return a; }
Re:Go 2 Draft Designs by chowells on Tuesday August 28, 2018 @06:30PM (#17863522)
Java does not have parametric polymorphism because instanceof exists in the language. That reduces what you can say about something from the type alone to "maybe parametric, maybe bounded by runtime checks that aren't visible in the type."

How many languages provide you a way to guarantee at the type level that the behavior of a function cannot be influenced by instantiation of type variables? I don't believe that to be true of anything that runs in the JVM or in .NET, for instance, as runtime type information is always available. C++ has dynamic_cast. What common language actually has parametricity expressed in the type system?

Re:Go 2 Draft Designs by whateveracct on Tuesday August 28, 2018 @08:01PM (#17864009)
That’s true..but Haskell has bottom and Scala has bottom + instanceOf checks and JVM reflection as well. And they clearly have usable parametric polymorphism despite things being “broken.”

Saying Java doesn’t have parametric polymorphism because you can cheat is like saying Haskell isn’t pure because of unsafePerformIO.

Re:Go 2 Draft Designs by pwm on Wednesday August 29, 2018 @06:08AM (#17867059)
Agreed. There is always a point where it's the developer's responsibility to write good code, even in languages where it's very difficult to shoot yourself in the foot.