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

181–190 of 439 posts

Re: Proposal: Go should have generics

#181

Post by fauigerzigerk »

sievebrain wrote: post #156
fauigerzigerk wrote: post #141

Earlier quoted context omitted.

Then your experience is very different from mine and that of many other people who resort to all sorts of off-heap solutions and distributing stuff across multiple VMs. I guess it depends a lot on the specific use case.

You can get 10msec pauses or less with heaps >100GB with HotSpot if you tune things well and use the latest GC (G1). If you want no GC pauses at all, ever, well, Go can't do that either. But if you are willing to pay money to Azul, you can buy a JVM that can. It also concurrently compacts the heap, which Go's GC does not. The issue is not Java. The issue is the quality of freely available garbage collectors, which ar…

>You can get 10msec pauses or less with heaps >100GB with HotSpot if you tune things well and use the latest GC (G1).

For what percentile of collections? I'm not wasting my time with incessant GC tuning only to delay that 5 minute stop the world pause for a bit longer. It's still going to hit eventually. For projects that might grow into that sort of heap size I use C++ (with an eye on Rust for the future).

You are right that Go is not a panacea for very large memory situations, but you can do a lot more before Go even needs that amount of memory.

The point is that languages without value types, such as Java and JavaScript, waste a huge amount of memory and generate a lot more garbage, thereby exacerbating all other related issues, including GC.

I have done quite a lot of testing for our workloads. Java memory usage is consistently two to three times higher than that of Go or C++. I'm unwilling to waste our money on that.

Re: Proposal: Go should have generics

#182

Post by stcredzero »

sievebrain wrote: post #154
omginternets wrote: post #70

Earlier quoted context omitted.

>you get the language simplicity And the most complex toolchain imaginable. This is what turns me off to Java, personally, but I think my case is fairly representative.

If popular Java toolchains are the most complex you can imagine, I assume you have never encountered autotools, or really any toolchain for a large C++ project. Toolchains normally mean build systems, debuggers, profilers, editors and other things. Java itself doesn't require any build tool at all, you could do it all with a custom shell script. The next step up after that is an IDE like IntelliJ where you press "new…

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

Re: Proposal: Go should have generics

#183

Post by pjmlp »

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?

I just know them from Java conferences.

Excelsior JET is the most well known one.

Oracle actually also supports AOT but only on embedded systems, with the commercial JDK.

Re: Proposal: Go should have generics

#184

Post by sievebrain »

fauigerzigerk wrote: post #181
sievebrain wrote: post #156

Earlier quoted context omitted.

You can get 10msec pauses or less with heaps >100GB with HotSpot if you tune things well and use the latest GC (G1). If you want no GC pauses at all, ever, well, Go can't do that either. But if you are willing to pay money to Azul, you can buy a JVM that can. It also concurrently compacts the heap, which Go's GC does not. The issue is not Java. The issue is the quality of freely available garbage collectors, which ar…

>You can get 10msec pauses or less with heaps >100GB with HotSpot if you tune things well and use the latest GC (G1). For what percentile of collections? I'm not wasting my time with incessant GC tuning only to delay that 5 minute stop the world pause for a bit longer. It's still going to hit eventually. For projects that might grow into that sort of heap size I use C++ (with an eye on Rust for the future). You are r…

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:

1. HBase setup with 100 GB heaps

2. Older collectors like CMS (still the default) sometimes take long pauses, like 5 seconds (not 5 minutes).

3. The new GC (G1) must be explicitly requested in Java 8. The plan is for it to be the default in Java 9, but switching to a new GC by default is not something to be taken lightly. G1 is, theoretically, configurably by simply setting a target pause time (lower == better latency but more CPU usage). Doing so eliminated all the long pauses, but a few collections were still 400msec (10x improvement over CMS).

4. With tuning, less than 1% of collections were over 300 msec and 60% of pauses were below the target of 100 msec.

Given that the Go collector, even the new one, isn't incremental or compacting I would be curious how effective it is with such large heaps. It seems to be that a GC that has to scan the whole 100GB every time, even if it does so in parallel, would experience staggeringly poor throughput.

Value types will certainly be a big, useful upgrade.

Re: Proposal: Go should have generics

#185

Post by chillydawg »

jcoffland wrote: post #112
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 you're copying and pasting then you're doing it wrong.

Not in go. You're allowed to in go. Because some googlers reckon that's cool.

Re: Proposal: Go should have generics

#186

Post by sievebrain »

kaffeinecoma wrote: post #180
sievebrain wrote: post #151

Earlier quoted context omitted.

The first company to make a fork of Go that runs on the JVM and has compiler-specific extensions will make a ton of money, IMO.

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 magical solution for bloat: eventually, they'll add the ability to break the runtime out into a dynamic library as it gets fatter and fatter.

Or of course they can just refuse to add features and doom their users to a mediocre, frustrating experience forever.

Re: Proposal: Go should have generics

#187

Post by aninhumer »

thegenius2000 wrote: post #165
tazjin wrote: post #125

Earlier quoted context omitted.

This is what people mean when they say that Go has disregarded everything we learned in the programming language community in the last decades. Sure, some people are productive in it and that's fine - but for those of us who have worked in better languages taking the step down is unattractive.

I'll grant that Go is lacking in generics, but IMHO, the opposite is true. Go is thriving because although not perfect, it is one of the few languages which seems to have learned lessons from the failings of C++, Java; and from the successes of the more dynamic/scripting languages (team Python, Ruby etc.). Go isn't a step down, it's a step backwards from the edge of the cliff.

The lesson Go seems to have learned is that, since C++ and Java burned their fingers, clearly fire is too dangerous for humans.

The thing that makes it painfully obvious to me that Rob Pike hasn't bothered to learn anything from the PL community is that Go has nil. That just shouldn't happen in a modern language.

Re: Proposal: Go should have generics

#188

Post by enneff »

junke wrote: post #104
enneff wrote: post #85

Earlier quoted context omitted.

Or, y'know, just copy and paste the trivial code. It should take all of 30 seconds. Not saying that it's pretty, but it's quick and easy.

And that's exactly why I am not convinced that Go is as maintainable as often claimed. 30 seconds for you, but how many hours for the poor souls who will come after you and ask: should I change this copy too or is it a separate case? It reminds me of this: http://typicalprogrammer.com/abject-oriented/

This thread is about sort interface implementations. Their general form will never change, and the only specifics unique to any given copy are those specific to their type. It is obvious to any Go programmer what can and cannot be changed in this situation.

Re: Proposal: Go should have generics

#189

Post by sievebrain »

zzzcpan wrote: post #170
sievebrain wrote: post #151

Earlier quoted context omitted.

The first company to make a fork of Go that runs on the JVM and has compiler-specific extensions will make a ton of money, IMO.

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 libraries that are out there, ability to mix in other non-Java languages too (javascript, ruby, R ...), code hotswap, better monitoring tools, a vastly larger standard library, better code synthesis tools and so on.

The JVM is hardly a liability. It adds features and carries a cost, but Go is substantially similar to Java in many ways and getting closer with time. I do not see any credible plan from the Go developers to beat the JVM developers in terms of GC or compiler quality, for instance.

Re: Proposal: Go should have generics

#190

Post by jgalt212 »

As an outsider, I've been following Go for a while, and given the lack of common high productive language features such as Generics and optional function arguments with default values, to me, it seems like right now Go is much better than C, and in some dimensions better than Java and in others worse.

If it just adds a few things, and then when you account for portability and speed, it could be better than the dynamic languages that people often compare it to.

Post reply on HN