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

The State of Go: Where we are in February 2016

talks.golang.org

Post reply on HN
Print view View original

111–120 of 224 posts

Re: The State of Go: Where we are in February 2016

#111

Post by mike_hearn »

BenoitP wrote: post #2

The Go runtime is really starting to look sexy. 20 ms GC pauses on 200+ GB heaps! I remember a thread discussing a pauseless GC on the dev mailing-list; where Gil Tene, of Azul C4's fame, commented on having a clear policy on safepoints from the beginning was paramount to having a good GC. It looked like the community is very biased towards doing the fundamental things well, and attracting the right people. And on to…

You have to be very careful about these sorts of GC statistics. Things are often not quite what they seem and they depend a lot on the type of app you run.

The first thing to be aware of is that with modern collectors (I have no idea how modern Go's new collector is though), GC pause time depends on how much live data there is in the young generation. So you can easily have enormous heaps with very low pause times if all your objects die young and hardly ever make it into the old generations, because then you never really need to collect the rest of the heap at all.

Of course, outside of synthetic benchmarks, many apps don't show such pleasant behaviour, and often GC algorithms face difficult tradeoffs that are only really knowable by the developers. For instance, do you want low pause times, or less CPU used by the collector (higher throughput)? It turns out that's a fundamental tradeoff and the right answer usually depends whether your app is a user facing server (needs low pause times) or a batch job (better to pause for long periods but complete faster). No runtime can know that, which is why the JVM has tons of tuning knobs. Left to its own devices you can theoretically get away with only tweaking a single knob which is target pause time (in G1). Set it lower and CPU usage of the collector goes up but it'll try and pause for less time. Set it higher and the collector gets more efficient.

Or you can just buy Zing and get rid of GC pauses entirely.

So a stat by itself like "20ms GC pauses on 200GB heaps" doesn't mean much by itself. You can get very low pause times with huge heaps out of the JVM as well:

  http://www.slideshare.net/HBaseCon/dev-session-7-49202969
but of course, you have to pay the piper somehow ... assuming non-weird heap usage the program will run slower overall.

Re: The State of Go: Where we are in February 2016

#112

Post by mike_hearn »

leaveyou wrote: post #56
loganekz wrote: post #49

Earlier quoted context omitted.

Although Go's GC is tunable to some extent, the open source HotSpot JVM are already has multiple GC implementations that you can choose based on your use case and further tune. There is also work being done in the OpenJDK project for a GC that can collect > 100GB heaps in [1] http://openjdk.java.net/jeps/189 [2] https://www.azul.com/products/zing/

From this "work being done in the OpenJDK project for a GC that can collect > 100GB heaps in https://talks.golang.org/2016/state-of-go.slide#37 https://github.com/golang/proposal/blob/master/design/12800-...

Depends what you compare it to. As I have written above, you can get low pause times with huge heaps today. In practice very few apps need such low pause times with such giant heaps and as such most users prefer to tolerate higher pauses to get more throughput. There are cases where that's not true, the high frequency trading world seems to be one, but that's why companies like Azul make money. You can get JVMs that never pause. Just not for free.

Re: The State of Go: Where we are in February 2016

#113

Post by notacoward »

iends wrote: post #57
armitron wrote: post #36

Am I in the minority to think of Go as a completely unnecessary move-along-now-nothing-to-see-here project? (as if we didn't have enough of that already). The only niche I see for it is for those poor souls who are still wasting their time with Python/Ruby but that by itself surely can't lead to great things for the language, especially since it's riding on air. More dense air than Python but air nonetheless. Also Ro…

The value of Go is: 1) Reasonably fast (better than Node at CPU bound tasks, faster than Ruby/Python) 2) Statically compiled 3) Great tooling (except package management, but it's getting better) If you want a reasonably fast statically compiled language, what would you use? Java? Lots of JEE/App server issues to consider TypeScript? I'm a fan, but it's compile time type checking and not runtime type checking. TypeClo…

> If you want a reasonably fast statically compiled language, what would you use?

Nim. More similar to Go than most languages are to each other, but Nim has (a) more modern features, (b) better compatibility/integration with C libraries, and (c) an amazing macro system. The only thing in Go's favor is the size of its community/ecosystem, which seems to be an accident of timing and most definitely not about inherent quality.

Re: The State of Go: Where we are in February 2016

#114

Post by freyr »

ebbv wrote: post #87
masklinn wrote: post #43

Earlier quoted context omitted.

This change simply draws from Jinja, which has had this feature for nearly 10 years[0]. It's a simple and efficient solution to the problem of trimming whitespace on either side of a template tag, I fail to see what is kludgy about it (and intuitiveness is in the eye of the beholder). In my experience it's clear, simple and doesn't make the template less readable. > Sure, it's terse and being terse can be nice, but t…

> The whole point of this feature is to be terse... I get that. I don't think you understood my objection, which was that being terse is not as important to me as being elegant and easily understood. {{foo -}} is not clear looking at it what that - is gonna do. You have to already know, or look it up. There is basically no way to know from context what the desired behavior is. That's bad design IMHO.

How much programming language syntax is really intuitive, as compared to what you've grown familiar with over time?

Once you use the Go(/Jinja/Perl) syntax once or twice, then putting a minus sign to remove whitespace will be easily understood.

I am interested in an alternative that you find more elegant.

Re: The State of Go: Where we are in February 2016

#115

Post by iends »

ssmoot wrote: post #65
iends wrote: post #57

Earlier quoted context omitted.

The value of Go is: 1) Reasonably fast (better than Node at CPU bound tasks, faster than Ruby/Python) 2) Statically compiled 3) Great tooling (except package management, but it's getting better) If you want a reasonably fast statically compiled language, what would you use? Java? Lots of JEE/App server issues to consider TypeScript? I'm a fan, but it's compile time type checking and not runtime type checking. TypeClo…

Please keep in mind I may have completely misinterpreted your comment. > Java? Lots of JEE/App server issues to consider Why? Why not just package as an assembly, scp it up to a server, fire up Netty in a main-class and call it a day (this is basically all Play Framework does)? It's going to be faster/simpler in every way than any Ruby/Nginx stack you can imagine. No need to fight with matching cores to processes per…

Sorry, I used to work at IBM and in my mind Java is WebSphere and a lot of suffering.

Certainly, there are other simple ways to use the Java stack with things like Play. DropWizard, etc.

But there is certainly a lot more complexity around tooling and deployments and such in the Java ecosystem than either Go or Node.js (although I can't say I'm a Java expert, so it could just be I'm just wrong).

Re: The State of Go: Where we are in February 2016

#116

Post by eloff »

mike_hearn wrote: post #111
BenoitP wrote: post #2

The Go runtime is really starting to look sexy. 20 ms GC pauses on 200+ GB heaps! I remember a thread discussing a pauseless GC on the dev mailing-list; where Gil Tene, of Azul C4's fame, commented on having a clear policy on safepoints from the beginning was paramount to having a good GC. It looked like the community is very biased towards doing the fundamental things well, and attracting the right people. And on to…

You have to be very careful about these sorts of GC statistics. Things are often not quite what they seem and they depend a lot on the type of app you run. The first thing to be aware of is that with modern collectors (I have no idea how modern Go's new collector is though), GC pause time depends on how much live data there is in the young generation. So you can easily have enormous heaps with very low pause times if…

Go doesn't use a generational GC AFAIK.

Re: The State of Go: Where we are in February 2016

#117

Post by iends »

notacoward wrote: post #113
iends wrote: post #57

Earlier quoted context omitted.

The value of Go is: 1) Reasonably fast (better than Node at CPU bound tasks, faster than Ruby/Python) 2) Statically compiled 3) Great tooling (except package management, but it's getting better) If you want a reasonably fast statically compiled language, what would you use? Java? Lots of JEE/App server issues to consider TypeScript? I'm a fan, but it's compile time type checking and not runtime type checking. TypeClo…

> If you want a reasonably fast statically compiled language, what would you use? Nim. More similar to Go than most languages are to each other, but Nim has (a) more modern features, (b) better compatibility/integration with C libraries, and (c) an amazing macro system. The only thing in Go's favor is the size of its community/ecosystem, which seems to be an accident of timing and most definitely not about inherent q…

There is very little chance I could sell a CEO on using Nim. The fact of the matter is that the community and ecosystem are parts of the entire platform and the platform matters a huge deal when you're betting your business on it. Accident or not.

Re: The State of Go: Where we are in February 2016

#118

Post by iends »

krisdol wrote: post #82
iends wrote: post #57

Earlier quoted context omitted.

The value of Go is: 1) Reasonably fast (better than Node at CPU bound tasks, faster than Ruby/Python) 2) Statically compiled 3) Great tooling (except package management, but it's getting better) If you want a reasonably fast statically compiled language, what would you use? Java? Lots of JEE/App server issues to consider TypeScript? I'm a fan, but it's compile time type checking and not runtime type checking. TypeClo…

>If you want a reasonably fast statically compiled language, what would you use? I'd go for rust.

Rust seems like a nice systems language, but is it really best suited for non-system programming? I may be too risk adverse, but it seems too early to make that bet at this point.

Re: The State of Go: Where we are in February 2016

#119

Post by _ph_ »

mike_hearn wrote: post #111
BenoitP wrote: post #2

The Go runtime is really starting to look sexy. 20 ms GC pauses on 200+ GB heaps! I remember a thread discussing a pauseless GC on the dev mailing-list; where Gil Tene, of Azul C4's fame, commented on having a clear policy on safepoints from the beginning was paramount to having a good GC. It looked like the community is very biased towards doing the fundamental things well, and attracting the right people. And on to…

You have to be very careful about these sorts of GC statistics. Things are often not quite what they seem and they depend a lot on the type of app you run. The first thing to be aware of is that with modern collectors (I have no idea how modern Go's new collector is though), GC pause time depends on how much live data there is in the young generation. So you can easily have enormous heaps with very low pause times if…

The GO gc is not generational, those 20ms are for a full gc. Certainly the details of the heap usage of the application is going to affect gc times, but this is not the time for just a nursery collection.

Re: The State of Go: Where we are in February 2016

#120

Post by notacoward »

iends wrote: post #117
notacoward wrote: post #113

Earlier quoted context omitted.

> If you want a reasonably fast statically compiled language, what would you use? Nim. More similar to Go than most languages are to each other, but Nim has (a) more modern features, (b) better compatibility/integration with C libraries, and (c) an amazing macro system. The only thing in Go's favor is the size of its community/ecosystem, which seems to be an accident of timing and most definitely not about inherent q…

There is very little chance I could sell a CEO on using Nim. The fact of the matter is that the community and ecosystem are parts of the entire platform and the platform matters a huge deal when you're betting your business on it. Accident or not.

Not disagreeing with you, but that only matters if you need to sell a CEO on your choice of language. Many of us don't, and every language had to cross that chasm somehow. Once upon a time, there were plenty of CEOs who didn't believe you should use Java for anything that mattered. Ditto for Javascript. Most relevantly, ditto for Go. If size of the existing community and ecosystem were the main criterion for choosing a language, Go would still be in the same bucket as Nim. Somebody has to use a language because of its own inherent strength before the CEOs can be convinced.
Post reply on HN