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

Go GC: Solving the Latency Problem in Go 1.5

sourcegraph.com

Post reply on HN
Print view View original

81–90 of 132 posts

Re: Go GC: Solving the Latency Problem in Go 1.5

#81

Post by BuckRogers »

omarforgotpwd wrote: post #13
nulltype wrote: post #8

Earlier quoted context omitted.

Have you encountered any problems with go GC pauses?

For many applications, like web backends that may have previously been written in Ruby, Python, or JavaScript, the garbage collector was not noticeable at all. Improvements to the garbage collector target apps that previously would have been written in C with manual memory management, as mentioned in the talk. Not all apps need to be written in C obviously, but this will help bring Go's concurrency primitives to plac…

That's exactly the awkward ground Go is in and why I stopped using it. It's not really necessary for any company's web backend I've worked on, the existing in Ruby/Python/JS works fine. Yet it can't compete with the other stuff out there, Rust, C(++), Erlang or soon Swift 2.0.

Though admittedly, some of these have a dismal concurrency story so I got to hand Go credit where it deserves.

Re: Go GC: Solving the Latency Problem in Go 1.5

#82

Post by pjmlp »

sitharus wrote: post #68
endymi0n wrote: post #67

Earlier quoted context omitted.

No, why should I? In Go I've finally found a language that's pragmatic, both fast to run and fast to think and write in. While evreyone's discussing its obvious shortcomings, I'm churning out working code faster than ever. Now somebody who isn't me is putting in big resources into making the language even better. Where's the reason to complain?

Why shouldn't you? One of the best parts of software development is the diversity of ideas. Learning a new way of doing things adds to your potential techniques. My main job is in a garbage collected language but I'm learning rust and know swift.

Besides Rust, only Cyclone, ATS and ParaSail offer similar ways of memory management[0].

It would be nice if Rust becomes mainstream, but it is still a very long way to go.

[0] D is adding some support for it as well.

Re: Go GC: Solving the Latency Problem in Go 1.5

#83

Post by Negitivefrags »

endymi0n wrote: post #67
Negitivefrags wrote: post #53

Earlier quoted context omitted.

> the use case becomes obvious It's only obvious if you assume that writing code without a GC is harder or takes longer. Have you used a language that supports automatic memory management but without a GC for any length of time? It's actually very nice.

No, why should I? In Go I've finally found a language that's pragmatic, both fast to run and fast to think and write in. While evreyone's discussing its obvious shortcomings, I'm churning out working code faster than ever. Now somebody who isn't me is putting in big resources into making the language even better. Where's the reason to complain?

If you don't want to, then don't. It's just generally a good idea to at least understand the alternatives before you proclaim one thing to be better than another.

Re: Go GC: Solving the Latency Problem in Go 1.5

#84

Post by Negitivefrags »

pjmlp wrote: post #82
sitharus wrote: post #68

Earlier quoted context omitted.

Why shouldn't you? One of the best parts of software development is the diversity of ideas. Learning a new way of doing things adds to your potential techniques. My main job is in a garbage collected language but I'm learning rust and know swift.

Besides Rust, only Cyclone, ATS and ParaSail offer similar ways of memory management[0]. It would be nice if Rust becomes mainstream, but it is still a very long way to go. [0] D is adding some support for it as well.

C++ also qualifies. std::unique_ptr and std::shared_ptr together form a very nice automatic memory management system.

Re: Go GC: Solving the Latency Problem in Go 1.5

#85

Post by pjmlp »

arcticbull wrote: post #32

I've worked with garbage collected languages (ruby, Java, Objective-C in the bad old days), automatic reference counting (Objective-C and Swift), in the Rust model and manual reference counting/ownership in C over about 15 years now. Having thought about this a lot, I just don't really understand why people continue to work on garbage collection. Non-deterministic lifecycle of objects/resources, non-deterministic pau…

> I'm curious, is there something I'm missing?

Working in large teams with disparate skill levels and high attrition, e.g. typical corporate jobs.

Manual memory management never works, because there is always someone that does the wrong thing that leads either to blow ups or security exploits, that take experts days to weeks to track down.

ARC is one step up, but requires deep knowledge of the code, where to place weak annotations. Also hinders performance in thread heavy code and those cascade deletions of data structures are no better than a GC pause.

Yes, it is also possible to "leak" in GCs, but it is not a leak on C sense, and they are quite easy to find with something like VisualVM or MAT.

Lifecyle of resources is very deterministic in GC languages, provided one uses the proper language constructs, such as using/with/try/scope/defer or high order functions.

Regarding the languages you mention, Ruby GC are not on the same ballpark as Java or .NET, for example.

Objective-C's GC was never going to be any example of performance given the constraints of working with C, to the point it was an huge failure and triggered Apple to switch to ARC instead.

Java has plenty of GCs from several certified JVMs to choose from. Not all of them are the same. Also only with Java 7 and 8, it acquired the necessary mechanisms (try-with resources and lambdas) to have deterministic resource usage with a GC.

Re: Go GC: Solving the Latency Problem in Go 1.5

#86

Post by pjmlp »

Negitivefrags wrote: post #84
pjmlp wrote: post #82

Earlier quoted context omitted.

Besides Rust, only Cyclone, ATS and ParaSail offer similar ways of memory management[0]. It would be nice if Rust becomes mainstream, but it is still a very long way to go. [0] D is adding some support for it as well.

C++ also qualifies. std::unique_ptr and std::shared_ptr together form a very nice automatic memory management system.

C++ doesn't enforce you to use them, while the other languages have their memory models enforced by the compiler, hence why I left C++ out.

In large teams no one can prevent the cowboy coder on the team to go C style on a large C++ codebase, specially when code reviews and static analysis are not used.

Re: Go GC: Solving the Latency Problem in Go 1.5

#87

Post by pjmlp »

amenghra wrote: post #66
felixgallo wrote: post #54

Earlier quoted context omitted.

ARC is pretty great, but it's still very possible to leak memory, and you can actually cause longer pauses when references go out of scope than well-tuned modern GCs can. So there's pluses and minuses, as in all things.

I think the advantage of ARC is not the potential for longer pause times but the fact that things are predictable & somewhat easier to debug. I think it's too bad that the GC/ARC choice also implies a language choice. For e.g. if we had the ability to choose between GC & ARC in Java, we would be able to get a better understanding of which memory model developers of Java enterprise software end up preferring.

There are JVMs with RC,

http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rcix-oops...

Re: Go GC: Solving the Latency Problem in Go 1.5

#88

Post by pjmlp »

crafn wrote: post #74
rurban wrote: post #69

Earlier quoted context omitted.

> I just don't really understand why people continue to work on garbage collection. > ... but I think it's time to walk away from GC Well, look at the arguments. GC advantages: * less memory (unless you use a semi-space GC) * faster * can handle cyclic refs (graphs, not only trees and linked lists) * trivial to use, less programmer errors What you got wrong: significant memory and CPU overhead. If you compare the mem…

From gamedev perspective: Every time I've prototyped something on a GC'd language (java, actionscript, javascript, ..) I soon find myself optimizing memory allocations and not making the game because the GC causes too much overhead and/or causes too long pauses and therefore makes the game feel miserable. It doesn't matter if there are some theoretical GC models which have Nowadays I prefer to use C not because I lik…

I bet it only works, because you work in small teams with highly skilled developers.

Re: Go GC: Solving the Latency Problem in Go 1.5

#89

Post by Skinney »

amenghra wrote: post #66
felixgallo wrote: post #54

Earlier quoted context omitted.

ARC is pretty great, but it's still very possible to leak memory, and you can actually cause longer pauses when references go out of scope than well-tuned modern GCs can. So there's pluses and minuses, as in all things.

I think the advantage of ARC is not the potential for longer pause times but the fact that things are predictable & somewhat easier to debug. I think it's too bad that the GC/ARC choice also implies a language choice. For e.g. if we had the ability to choose between GC & ARC in Java, we would be able to get a better understanding of which memory model developers of Java enterprise software end up preferring.

You loose the predictability if you get longer pause-times. Memory leaks can also severely hurt development time when you spend days or weeks chasing down memory leaks (personal experience). You're not immune to memory leaks (space leaks really) in a GC based system, but it's generally easier to reason about where the system is using memory.

In regards to resources, who depends on lifecycles in a GC based system to handle resources? try-with-resources in Java is just as predictable as destructors in C++, with the added benefit of resources being eventually closed in case you forget to close it (wheras a memory leak in C++ will never close said resource)

Re: Go GC: Solving the Latency Problem in Go 1.5

#90

Post by fauigerzigerk »

derefr wrote: post #46
arcticbull wrote: post #32

I've worked with garbage collected languages (ruby, Java, Objective-C in the bad old days), automatic reference counting (Objective-C and Swift), in the Rust model and manual reference counting/ownership in C over about 15 years now. Having thought about this a lot, I just don't really understand why people continue to work on garbage collection. Non-deterministic lifecycle of objects/resources, non-deterministic pau…

I'm just as confused as you are about most implementations of garbage collection. There's one that feels like it works, though: Erlang's. Erlang doesn't do anything different in its GCing algorithms or anything; it just gives each (really tiny) process its own heap, so there's lots of heaps, which can each be GCed at some opportune time when that particular (tiny) process isn't scheduled. It's stop-the-world GC, but…

If that works or not depends on the application. It doesn't work for large in-memory datasets that are acessed by multiple processes.
Post reply on HN