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

271–280 of 439 posts

Re: Proposal: Go should have generics

#271

Post by NateDad »

junke wrote: post #260
NateDad wrote: post #241

Earlier quoted context omitted.

It's 3 lines of code the most newbie of newbies could understand... if this is the biggest problem I have in my day to day programming, I'll be happy. Is it mildly annoying to type out those three lines? Sure. You know what's a lot more annoying? Basically everything else in programming.

The problem with code duplication is not about being lazy, or having to type. I love typing. When you dive into a codebase full of vaguely similar yet different blocks, it starts being more than mildly annoying to understand the intent of the code and make the correct change.

nobutseriously...

    type userList []*User
    
    func (u userList) Len() int           { return len(u) }
    func (u userList) Swap(i, j int)      { u[i], u[j] = u[j], u[i] }
    func (u userList) Less(i, j int) bool { return u[i].Name()
What change would you ever need to make to this code that would be at all difficult? The first two methods on userList are never ever ever going to change. The only thing you could possibly want to change is how to sort inside the Less method... and that code would be the exact same code you'd have to change no matter what language you're in. You still have to define the sort one way or another for non-trivial types.

So, yes, it's some extra typing... but saying that it makes maintenance harder is just plain wrong.

Re: Proposal: Go should have generics

#272

Post by sievebrain »

fauigerzigerk wrote: post #210
sievebrain wrote: post #184

Earlier quoted context omitted.

In a properly tuned system with sufficient CPU capacity there should never be any full GC pauses with G1. To get 10msec pause times with such huge heaps requires burning a LOT of CPU time with the standard JDK collectors because they can trade off pause latency vs CPU time. This presentation shows tuning with 100msec as the target: http://www.slideshare.net/HBaseCon/dev-session-7-49202969 Key points from the slides:…

>In a properly tuned system with sufficient CPU capacity there should never be any full GC pauses with G1. So you use a language without value types that makes you pay for two or three times more memory than comparable languages, and then you spend your time re-tuning the GC every time your allocation or usage patterns change. Then you hope to never trigger a full GC that could stall the VM for many seconds (or in ex…

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 data. That's a big hit right there. And yes, you have to tune the Go GC:

https://github.com/golang/go/issues/14161

Even when Java gets value types, it won't magically slash memory usage in half. Pointer overheads are not that large.

Re: Proposal: Go should have generics

#273

Post by sievebrain »

krakensden wrote: post #251
stcredzero wrote: post #182

Earlier quoted context omitted.

The IDE's build system will do it all for you. There is no complexity.

The siren song of just-one-more-layer.

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 system does not provide enough features or you'd like your codebase to be IDE independent, you can also use a separate build tool, or a combination of both (in which case the IDE will sync itself to the other build tool).

In that case there are two layers. But Go does not have any magical solution to that. There will be Go apps that need more than the little command line tool can do as well.

Re: Proposal: Go should have generics

#274

Post by treehau5 »

idobai wrote: post #117
dom96 wrote: post #107

Maybe instead of adding generics to Go it's time to look into alternative programming languages which already implement generics, like for example Nim.

You forgot that most of golangers are ex-php programmers and students with no experience. Just look at what they're talking about: they think generics are the opposite of simplicity and can make performance and compilation time worse. Meanwhile, Nim has generics with other useful features and has faster compilation time along with better optimization. If google would put 'goto' into go golangers would still use it an…

> You forgot that most of golangers are ex-php programmers and students with no experience.

How hopelessly smug and incorrect.

Re: Proposal: Go should have generics

#275

Post by sievebrain »

geodel wrote: post #214
sievebrain wrote: post #189

Earlier quoted context omitted.

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…

Go GC since 1.6 openly claims In my experience Java brings a mindset that there must be some complex way to solving a problem so lets find out that.

Go 1.6 GC is exactly what I mean. It's a design that gives tiny pauses by not being generational, or incremental, or compacting. Those other features weren't developed by GC researchers because it was more fun than Minesweeper. They were developed to solve actual problems real apps had.

By optimising for a single metric whilst ignoring all other criteria, Go's GC is setting its users up for problems. Just searching Google for [go 1.6 gc] shows the second result is about a company that can't upgrade past Go 1.4 because newer versions have way worse GC throughput: https://github.com/golang/go/issues/14161

Their recommended solution is, "give the Go app a lot more memory". Well, now they're back in the realm of GC tuning and trading off memory to increase throughput. Which is exactly what the JVM does (you can make the JVM use much less memory for any given app if you're willing to trade it off against CPU time, but if you have free RAM then by default the JVM will use it to go faster).

BTW the point of an optimising compiler is to make code run faster, not reduce memory usage. Go seems to impose something like a 3x overhead vs C, at least, that was the perf hit from converting the Go compiler itself from C to Go (which I read was done using some sort of transpiler?). The usual observed overheads of Java vs C are 0 to 0.5x overhead. The difference is presumably what the compilers can do. Go's compiler wasn't even using SSA form until recently, so it's likely missing a lot of advanced optimisations.

tl;dr - I have seen no evidence that the Go developers have any unique insight or solutions to the question of building managed language runtimes. They don't seem to be fundamentally smarter or better than the JVM or .NET teams. That's why I think eventually Go users will want to migrate, because those other teams have been doing it a lot longer than the Go guys have.

Re: Proposal: Go should have generics

#276

Post by NateDad »

sievebrain wrote: post #269
NateDad wrote: post #246

Earlier quoted context omitted.

100GB heap size in Go? How about 15ms pauses with zero tuning? https://pbs.twimg.com/media/CWoAGeUW4AAy0-9.png:large

They aren't comparable at all. Go doesn't collect incrementally and doesn't compact. So good luck collecting garbage fast enough to keep up with a heap-heavy app (which if you have a 100GB heap, your app probably is). In other words, the issue is not pause time, it's also throughput. And Go users do tune their GC: https://github.com/golang/go/issues/14161

But Go programs use way less memory than Java applications... so the java application that uses 100GB might only use 40GB (or less) in Go. And there are tweaks you can make to hot code in Go to not generate garbage at all (pooling etc).

Re: Proposal: Go should have generics

#277

Post by waimbes »

_uhtu wrote: post #244
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.

Dart is also Google sponsored and no one uses it despite the fact that it's actually a pretty great general purpose language. People use go because it's productive and had a PHENOMENAL standard library for networking.

> Dart is also Google sponsored and no one uses it despite the fact that it's actually a pretty great general purpose language.

Citing an example that had support from Google and failed does not refute the claim that Go would have failed if not for Google's support.

Re: Proposal: Go should have generics

#278

Post by Arzh »

alkonaut wrote: post #202
Loic wrote: post #94

Earlier quoted context omitted.

I had the same feeling first. But practically in my code, I found that ok, you need to copy/paste a bit first but then if it works it stays there, you are not "sorting" new kind of "types" every day. The time spent on coding is way more "around" the algorithms than "within" them. I suppose that we will see more and more code generators which will practically remove the need of generics. We already use them without co…

If code generation is used to make up for something missing in a language (be it generics, metaprogramming etc.) then that's a pretty clear sign something is wrong. It's definitely acceptable to use a workaround for a missing feature once or twice in a language, because no language is perfect, and no language benefits from being burdened with all features imaginable. But if a workaround becomes part of the day-to-day…

Code generation is not about a deficiency in the language, C++ has templating but I will often use code generation since you only need to run that once and templating bloats the compile time for ever.

Re: Proposal: Go should have generics

#279

Post by NateDad »

dominotw wrote: post #259
NateDad wrote: post #254

Earlier quoted context omitted.

map and filter are often just syntactic sugar for a loop, so I just write a loop. I work on a ~1M LOC codebase in Go and it's really not a problem. map and filter would not make my life significantly easier. They're solving easy problems. Sure, I have some of this style code: var names []string for _, m := range machines { names = append(names, m.Name) } But, really, is that so much worse than this? names = [m.Name f…

>> But, really, is that so much worse than this? names = [m.Name for m in machines] You can take that code and interpret that as database query, like C# LINQ. you frist example is 'how' vs 'what' of second example. Once you stop telling the computer how to do things and just tell it what you want all kinds of things become possible.

But then you have no idea what the computer is actually doing. There's a big performance difference between an in-memory loop and querying a database. This is one of the things I like about Go... what the computer actually does in response to any random line of code is pretty obvious (except for function calls, which of course can do anything). When you hide away the loop inside a map statement, you get people doing dumb things like this:

    names = [m.Name for m in machines]
    ids = [m.ID for m in machines]
    addrs = [m.Address for m in machines]
So now we're iterating of over the list of machines 3 times... or making 3 database queries or whatever.

Re: Proposal: Go should have generics

#280

Post by codemac »

NateDad wrote: post #254
insulanian wrote: post #243

My code is full of map, filter, reduce/fold and similar generic reusable functions. How do people deal with such things in Go? Do they really make copies of such functions for every type they're working with? (And by type I don't mean just int/string, but all model entities/classes.)

map and filter are often just syntactic sugar for a loop, so I just write a loop. I work on a ~1M LOC codebase in Go and it's really not a problem. map and filter would not make my life significantly easier. They're solving easy problems. Sure, I have some of this style code: var names []string for _, m := range machines { names = append(names, m.Name) } But, really, is that so much worse than this? names = [m.Name f…

It's not about how hard or easy the code is to write, at all.

Any line of code you don't write, is a bug you didn't write either. I worked on a significantly size go codebase and the number of stupid bugs that popped up, like bad loops instead of a simple `filter` function, were just silly.

Having all this memory safety and other stupid bugs ruled out but not map, filter, or reduce just felt lazy on the Go authors part.

Of course, now that a member of the go team has said it, we'll see a huge shift in what the go team thinks about generics. I'm glad I don't deal with the go community anymore.

Post reply on HN