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

321–330 of 439 posts

Re: Proposal: Go should have generics

#321

Post by geodel »

coldtea wrote: post #130
ViktorasM wrote: post #24

Earlier quoted context omitted.

but having all those things go would become another C++ with a different syntax. I like the direction Go is going of "there are no options to choose", like unconfigurable fmt, or the fact that there is no way to create "exotic" implementations. However, generics would be my number #1 on the list of "maybe let's add that". Would be nice to have less "interface {}" in reusable libraries. Exceptions would be probably se…

> but having all those things go would become another C++ with a different syntax. Haskell and CL have "all those things" and they are not "C++ with a different syntax". I don't know why people repeat these cliches... It's not like a language can't have many features and be designed well at the same time. It just takes preparation and effort instead of ad-hoc additions (like with C++).

But then there need not be raging debate about Go/Generics. As pragmatic developers can move to Haskell etc if Go has no value add to them.

Re: Proposal: Go should have generics

#322

Post by nostrademons »

sythe2o0 wrote: post #302
nostrademons wrote: post #264

Earlier quoted context omitted.

It means that every single type in the language has one extra value it may contain, 'nil', and your code will crash or behave erratically if it contains this value and you haven't written code to handle it. This has caused billions of dollars in software errors (null dereferences in C/C++, NullPointerExceptions in Java, etc.). See "Null References: The Billion Dollar Mistake" by Tony Hoare, the guy who invented it: h…

nil in Go doesn't work that way. Most types cannot be nil.

Interesting, because (reading up on this) value types can not be nil.

How often does typical Go code use values vs. interfaces or pointers? It seems like the situation is pretty similar to modern C++, which also does not allow null for value or reference types (only pointers) and encourages value-based programming. Nil is still a problem there, but less of one than in, say, Java, where everything is a reference.

Re: Proposal: Go should have generics

#323

Post by sievebrain »

fauigerzigerk wrote: post #315
sievebrain wrote: post #272

Earlier quoted context omitted.

Java's higher memory usage is not only related to value types, for example, in Java 8 strings always use 16 bit characters. That is fixed in Java 9. It resulted in both memory savings and speed improvements. There are other sources of overhead too, but again - you seem to think Go has some magic solution to these problems. Since the new GC, Go is often using a heap much larger (such as twice the size) of actual live…

Value types are the main culprit behind Java's insane memory consumption. I found out through weeks of testing and benchmarking. I mostly benchmarked a small subset of our own applications and data structures. We use a lot of strings, so I never even started to use Java's String class, only byte[]. I tried all sorts of things like representing a sorted map as two large arrays to avoid the extra Entry objects. I imple…

I admire your dedication to optimisation!

But I think your conclusion is not quite right. I said above that pointer overhead is only one source of Java memory consumption, and pointed to (hah) strings as another source. You replied and said no, it's all pointers, followed by "I never even started using strings". Do you see why that approach will lead to a tilted view of where the overheads are coming from?

If your application is so memory sensitive that you can't use basic data structures like maps or strings then yes, you really need to be using C++ at that point.

In theory, especially once value types are implemented, it would be possible for a Java app to have better memory usage than an equivalent C++ app, as bytecode is a lot more compact than compiled code and the JVM can do optimisations like deduplicate strings from the heap (already). Of course how much that helps depends a lot on the application in question. But the sources of gain and loss are quite complex.

Re: Proposal: Go should have generics

#324

Post by sievebrain »

omginternets wrote: post #282
sievebrain wrote: post #273

Earlier quoted context omitted.

I don't see your point. If you have a collection of source files, then something must search the directory tree to find them and feed them to the compiler ... ideally, only the files that have changed, to give fast incremental compilation. If you use a typical Java IDE like IntelliJ then the program that does that will be the IDE. There is no "one more layer" because that's the first and only layer. If the IDE build…

>typical Java IDE like IntelliJ So now I need to change my text editor?

No. If you want to use vim then you would just use Gradle or Maven as your build system, instead of Make.

Re: Proposal: Go should have generics

#325

Post by mlvljr »

idobai wrote: post #123
duaneb wrote: post #18

Earlier quoted context omitted.

Generics are not "all the things". Last i checked there was still no object inheritance (in a subtype sense for interface implementations), no operator overloading, no bytecode/vm/jit, no inline asm, no macros, no pluggable gc, no call/cc, no (idiomatic) exceptions, no currying, no weak typing or implicit conversions, no way of enforcing referential transparency, no STM, no laziness, no assertions, no contracts, no u…

> EDIT: of course this is good; such a language would be beyond nightmarish. By which i mean c++ or scala. Then go and compare the same code in go and Scala and see which is more "nightmarish". You see Scala as a complex language because you need to learn something before you use it while go is almost the opposite - you may get it in an afternoon and create repetitive, boilerplatish and unmaintanable mess.

This Scala maintainer disagrees, as we know:

https://www.youtube.com/watch?v=TS1lpKBMkgg

Re: Proposal: Go should have generics

#326

Post by d4rkph1b3r »

NateDad wrote: post #301

I work on juju ( https://github.com/juju/juju ), which all told is about 1M LOC. In my almost 3 years on the project, I have not been bothered by lack of generics, basically at all (and I worked for 10 years in C# on projects that used a lot of generics, so it's not like I don't know what I'm missing). Do we have 67 implementations of sort.Interface? Sure. Is that, by any stretch of the imagination, a significantly d…

>Do we have 67 implementations of sort.Interface?

Hahaha. This has to be satire right?

>Generics would not make our codebase significantly better, more maintainable, or easier to understand.

Generics are literally a form of abstraction. You might as well be arguing that abstraction doesn't help. Why do you even have subtype polymorphism then? Why not just reimplement everything? That's not a significantly difficult part of your job as you said.

One of the best things about Go is it seems to be a strong signaler of the type of engineering team I avoided.

Re: Proposal: Go should have generics

#327

Post by stcredzero »

jdcarter wrote: post #314
NateDad wrote: post #301

I work on juju ( https://github.com/juju/juju ), which all told is about 1M LOC. In my almost 3 years on the project, I have not been bothered by lack of generics, basically at all (and I worked for 10 years in C# on projects that used a lot of generics, so it's not like I don't know what I'm missing). Do we have 67 implementations of sort.Interface? Sure. Is that, by any stretch of the imagination, a significantly d…

I've had a very similar experience from about 3 years of writing Go. The lack of generics hardly affected me. When it did, it was dead simple to write the type-specific code and move on. I've been working on a Java project recently, and by contrast, this code base abuses generics to an almost pathological level. I've also been burned by Java's runtime type erasure, and wow that leads to some nasty bugs. (That's not t…

Too often I've seen [X] lead to complexity and abuse which greatly outweigh their utility.

Programmer hubris is a problem. There was a widely acknowledged problem in Smalltalk with the overuse of #doesNotUnderstand: and other esoterica to do "clever" stuff which then makes it difficult for new programmers to debug and understand the system.

There is a reason why certain methodologies emphasize "the simplest thing that could possibly work." As a group, we programmers sometimes waste our own and other's time being too clever by half...an order of magnitude. (Is it any wonder why our estimates are often off by that much?)

Re: Proposal: Go should have generics

#328

Post by Scarbutt »

zellyn wrote: post #213
pjmlp wrote: post #208

Earlier quoted context omitted.

Go is thriving because it is Google sponsored. If it came from "Joe the dev" no one at HN would give it a second look.

I simply do not believe this. I believe it is thriving because it was well-designed, by extremely influential individuals, and the early library work was stellar. Also, several other experienced and influential programmers tried it, and expressed something along the lines of "programming is fun again!" Inside Google, the two main programming languages are C++ and Java, not Go (at least when I left, in September). The…

Redhat or Apple are not "Joe the dev" though

Re: Proposal: Go should have generics

#329

Post by stcredzero »

d4rkph1b3r wrote: post #326
NateDad wrote: post #301

I work on juju ( https://github.com/juju/juju ), which all told is about 1M LOC. In my almost 3 years on the project, I have not been bothered by lack of generics, basically at all (and I worked for 10 years in C# on projects that used a lot of generics, so it's not like I don't know what I'm missing). Do we have 67 implementations of sort.Interface? Sure. Is that, by any stretch of the imagination, a significantly d…

>Do we have 67 implementations of sort.Interface? Hahaha. This has to be satire right? >Generics would not make our codebase significantly better, more maintainable, or easier to understand. Generics are literally a form of abstraction. You might as well be arguing that abstraction doesn't help. Why do you even have subtype polymorphism then? Why not just reimplement everything? That's not a significantly difficult p…

Generics are literally a form of abstraction

Is your unstated assumption then that all forms of abstraction must be used? If you've done substantive projects, you'll come to realize that abstractions have a cost, and that everything should be considered on a cost/benefit basis.

You might as well be arguing that abstraction doesn't help.

This is a black and white binary fallacy invoked to then create a straw man, which also seems to suggest that you haven't learned the importance of considering cost/benefit.

One of the best things about Go is it seems to be a strong signaler of the type of engineering team I avoided.

I would agree, this would seem to be a good signaler.

Re: Proposal: Go should have generics

#330

Post by eternalban »

d4rkph1b3r wrote: post #326
NateDad wrote: post #301

I work on juju ( https://github.com/juju/juju ), which all told is about 1M LOC. In my almost 3 years on the project, I have not been bothered by lack of generics, basically at all (and I worked for 10 years in C# on projects that used a lot of generics, so it's not like I don't know what I'm missing). Do we have 67 implementations of sort.Interface? Sure. Is that, by any stretch of the imagination, a significantly d…

>Do we have 67 implementations of sort.Interface? Hahaha. This has to be satire right? >Generics would not make our codebase significantly better, more maintainable, or easier to understand. Generics are literally a form of abstraction. You might as well be arguing that abstraction doesn't help. Why do you even have subtype polymorphism then? Why not just reimplement everything? That's not a significantly difficult p…

   package pleasePutMeInYourVendorsDir

   import (
      "io"
       ...
   )
   ...

   func sureYouCan() {
      // ...
      io.EOF = io.ErrShortWrite
      // ...
   }
Post reply on HN