Go 1.5 Release Candidate 1 is released | Hacker News Reader

Go 1.5 Release Candidate 1 is released

groups.google.com

63 pointssajal8317 comments

Huge improvements to the GC in this release, illustrated in this slide deck linked from the notes: https://talks.golang.org/2015/go-gc.pdf

> Tell people that GC is not a barrier with Go’s low latency GC

If you have a time target of 350us, then a 3 millisecond pause means you are dead. So you either write Go in such a fashion as to not create junk or use c++. Systems and time sensitive languages cannot have GC.

While GC is always going to take some resources, the new Go 1.5 GC will bring the latency down such that a lot more use cases will be able to consider it. Going from seconds to milliseconds is huge.

> Systems and time sensitive languages cannot have GC.

This is not true, as not all GCs are stop-the-world, and all GC systems have some sort of pool system allowing you to manage/batch your allocations and sweeps. Root all your allocations for the inner loop, and unroot them/trigger a release when ready.

> This is not true, as not all GCs are stop-the-world, and all GC systems have some sort of pool system allowing you to manage/batch your allocations and sweeps. Root all your allocations for the inner loop, and unroot them/trigger a release when ready.

Not for all allocations. You can manually do it for a subset of them, but pooling all allocations is generally extremely impractical.

How do you, for example, pool the allocations that closures or defer perform?

> How do you, for example, pool the allocations that closures or defer perform?

It's a strange area that demands reliable or stable performance but uses closures and exceptions, two ways to inject a healthy amount of noise into your understanding of the program, and certainly blows the upper bound on "arbitrary wait time" to huge. I haven't been presented with a problem yet that allowed you to complain about GC with respect to latency where you would want implicit allocations happening all over the case....

You can't get away from exceptions in Go. Closures, maybe, depending on the code you're writing (though I doubt it), but the highly dynamic semantics of defer makes it impossible to avoid.

Are there GC'd languages that can get to 350us?

Erlang doesn't share data between VM processes (green threads) and each process has its own heap, so you don't need to stop-the-world. Your GC can run concurrently with other live processes while still serving clients. Erlang also gives you the ability to manually invoke the garbage collector per-process so you can run it at more optimal times of your own choosing.

It is going to be difficult to achieve a hard 350 us minimum latency requirement on a general-purpose OS with a virtual memory system, regardless of the allocator you are using.

That you need to unmount swap (and change the overcommit memory setting) is a given, even for soft-real-time.

Hard realtime linux systems do that as a basic given, and all real-time code I've ever seen was C, C++ or SmallTalk, and effectively bypasses the kernel entirely.

Is there an Azul equivalent for SmallTalk?

The improvements look fantastic! Great job GO team! I'm still more of a fan of the way C++ or Rust go about memory management but one of the great detractors to using GO for me has always been the latency issues (well that and the forced file structure but that's off topic).

I may have to give GO another shot with 1.5.

Anyone know what happened to LiteIDE? The creator went radio silent all of a sudden a couple months back.

Sheesh! You don't have to put go in it's name just because it is written in go[0].

[0] https://twitter.com/rob_pike/status/618357610287226880

Ha! https://github.com/robpike/nihongo

I never realized how odd it is, etymological, to release a release candidate before.

Reply on news.ycombinator.com