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

Proposal: Go should have generics

github.com

Post reply on HN
Print view View original

191–200 of 439 posts

Re: Proposal: Go should have generics

#191

Post by bad_user »

possibility wrote: post #174
bad_user wrote: post #168

Earlier quoted context omitted.

I think Go people have a very strange definition for simplicity, much like the population at large actually, but that's a shame really. Simple means composed of a single element, not compound, unentangled, being the opposite of "complex", which of course means consisting of many different and connected parts. Instead Go people prefer the term to mean the now more popular meaning, which is " easy to understand, famili…

Tying your two examples together, the GPL version of free/libre is way more complex than the simple BSD version.

True, GPL is significantly more complex, as it makes a difference between usage and distribution, not to mention it tries to prevent loopholes, like Tivoization and patent threats. Complex is not necessarily worse, of course it depends on context. I prefer APL 2 if you ask me.

But what matters in this case are that both correspond to the open source and free software definitions. For such licenses it means that there are things you can rely on. Like you know usage is OK for any purpose, including commercial ones. You know that you can share it with anybody, you know that derivate works are OK, again for any purpose, even though you can have restrictions on distribution. Etc.

For me clear definitions are important because then you immediately know what you can rely on and ambiguous language is bad because then we can't have a meaningful conversation. Are generics complicated? No. Are Java's generics complicated? Yes, but that's only because it was added later ;-)

Re: Proposal: Go should have generics

#192

Post by brightball »

mattlondon wrote: post #68

I can feel the pain on the Sort issue. I've personally found sorting annoying in Go - I had a bunch of structs representing data entities from a database that all had the same field and I wanted to be able to sort them by this field. Seemed like a LOT of work (basically implementing the same sort that was 99% identical for every struct) or use weird reflection-workarounds to get this to happen. In Java I would not ev…

Couldn't you create a common interface that you could use for the sort?

Re: Proposal: Go should have generics

#194

Post by zzzcpan »

sievebrain wrote: post #189
zzzcpan wrote: post #170

Earlier quoted context omitted.

This will only target a very small group of developers, who are comfortable with JVM, but not with Java or Scala. I don't see any money there. JVM is a major drawback for any language. Many people don't even look at JVM languages.

No, it's the opposite. It would appeal to people who built large Go codebases and eventually realised that they were tied to a toolchain that was years behind the state of the art. A Go for the JVM would immediately give Go developers much better optimising compilers, high quality cross platform IDE-integrated debugging and profiling, much stronger garbage collectors, ability to access the large quantity of Java libr…

JVM cannot appeal to Go developers, because compiler is a significant factor why people choose Go in the first place.

Re: Proposal: Go should have generics

#195

Post by sievebrain »

fosk wrote: post #73
pjmlp wrote: post #50

Earlier quoted context omitted.

If you have the money, there are lots of commercial JVMs with compilers to native code. There are quite a few open source ones, but they aren't as stable. As always, Language != Implementation.

Could you recommend any that you have had experience with?

RoboVM is one that compiles AOT ARM binaries, it's intended for the iPhone but it runs on MacOS too.

Avian is a JIT compiling JVM but one which is much smaller than HotSpot. It has a mode where it statically links your JAR into the binary itself, so you get a single self contained executable. With ProGuard and other optimisations like LZMA compression built in, such binaries can be remarkably small. Try their example:

https://readytalk.github.io/avian/#-xamples

It's a full blown GUI app that demonstrates the full range of widgets available, is cross platform, and yet is only about 1mb in size.

Re: Proposal: Go should have generics

#196

Post by tel »

eru wrote: post #65
pcwalton wrote: post #16

Earlier quoted context omitted.

Generics are a very simple feature as implemented in, for example, SML or OCaml. They're much simpler than Go interfaces, in fact.

Generics become complicated when you have other subtype relationships, don't they? (That's why SML, OCaml and Haskell don't really do inheritance, isn't it?)

Generics and many kinds of subtyping do cause challenges. This is part of why Scala's type inference is so bad.

Re: Proposal: Go should have generics

#197

Post by mseepgood »

sievebrain wrote: post #186
kaffeinecoma wrote: post #180

Earlier quoted context omitted.

I doubt it. I did Java for over a decade, but jumped at the opportunity to use Go with its statically compiled binaries. The JVM is great, but being tied to it is kind of a hassle. Being able to hand a small binary to someone and say "here, run this" with no worry about dependencies- it's a beautiful thing.

The downsides are enormous. You can use the 'javapackager' tool in Java 8 to make a tarball that contains a JRE. It's not small, but that's a result of the age of the platform; it just has a lot of features (in Java 9 there is a tool that can make a bundled but stripped and optimised package). Go binaries are getting larger and the compiler is getting slower over time, as they add features. They don't have any magica…

Go 1.7 (tip) binaries are smaller than Go 1.4 binaries.

Re: Proposal: Go should have generics

#198

Post by ImJasonH »

mattlondon wrote: post #68

I can feel the pain on the Sort issue. I've personally found sorting annoying in Go - I had a bunch of structs representing data entities from a database that all had the same field and I wanted to be able to sort them by this field. Seemed like a LOT of work (basically implementing the same sort that was 99% identical for every struct) or use weird reflection-workarounds to get this to happen. In Java I would not ev…

I made this: https://github.com/imjasonh/tros

It's slower than doing it yourself but for normal-sized slices you shouldn't notice.

Also https://github.com/bradfitz/slice which is similar but faster and relies on more unsafe black magic.

Re: Proposal: Go should have generics

#199

Post by enneff »

masklinn wrote: post #148
reycharles wrote: post #80

Earlier quoted context omitted.

> you get the language simplicity I remember the Go language specification to be about as long as the table of contents for the Java language specification. On the other hand, Brainfuck is an extremely simple language, too.

> I remember the Go language specification to be about as long as the table of contents for the Java language specification. I'm not sure where you got that from. On my browser and screen, the JLS8 TOC[0] is 16 pages high which brings me about 20% into the Go language spec[1]. But then again that's a completely inane appeal to emotions: because it's a specification for cross-platform and cross-implementation compatib…

> Go's language spec is a much fuzzier document targeted towards language users — much like e.g. Python's language reference — there is no way you can write a clean-slate implementation just from the language spec.

That's not correct. The Go spec is designed to be a precise specification of the language, targeted at language implementers. Ian Lance Taylor (incidentally, the author of these generics proposals) wrote gccgo based on that spec. There have been a couple of other implementations based on that spec since.

The main Go compiler itself was implemented from that spec, too. The spec comes first.

Re: Proposal: Go should have generics

#200

Post by enneff »

reycharles wrote: post #161
masklinn wrote: post #148

Earlier quoted context omitted.

> I remember the Go language specification to be about as long as the table of contents for the Java language specification. I'm not sure where you got that from. On my browser and screen, the JLS8 TOC[0] is 16 pages high which brings me about 20% into the Go language spec[1]. But then again that's a completely inane appeal to emotions: because it's a specification for cross-platform and cross-implementation compatib…

You are absolutely right, it's a silly comparison. The Go language spec is indeed vague. I did this comparison a while ago. It wasn't very accurate. The Go spec has probably changed. Unfortunately, it seems they don't keep older specs around(!) If I adjust the font size in the ToC of the JLS I get 23 pages and the Go Spec is 84 pages (27%). Not quite "about the same length", still. I took a compiler course in univers…

> Unfortunately, it seems they don't keep older specs around(!)

https://github.com/golang/go/commits/master/doc/go_spec.html

Post reply on HN