4 ms·

Go 1.5 Release Candidate 1 is released

63 points by sajal83 11y ago

Zikes 11y ago
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 https://talks.golang.org/2015/go-gc.pdf
- easytiger 11y ago
  > 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.
  - duaneb 11y ago
    > 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.
    - pcwalton 11y ago
      > 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?
      - duaneb 11y ago
        > 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....
        pcwalton 11y ago
        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.
  - Zikes 11y ago
    Are there GC'd languages that can get to 350us?
    - seiji 11y ago
      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. Related: http://www.evanmiller.org/why-i-program-in-erlang.html http://www.evanmiller.org/why-i-program-in-erlang.html
  - bbrazil 11y ago
    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.
  - cwzwarich 11y ago
    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.
    - iofj 11y ago
      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.
      - proveanegative 11y ago
        Is there an Azul equivalent for SmallTalk?
0xdeadbeefbabe 11y ago
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 https://twitter.com/rob_pike/status/618357610287226880
- Zikes 11y ago
  Ha! https://github.com/robpike/nihongo https://github.com/robpike/nihongo
Coding_Cat 11y ago
I never realized how odd it is, etymological, to release a release candidate before.
BinaryIdiot 11y ago
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.
Rapzid 11y ago
Anyone know what happened to LiteIDE? The creator went radio silent all of a sudden a couple months back.

63 points by sajal83 11y ago

Zikes 11y ago

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 https://talks.golang.org/2015/go-gc.pdf

easytiger 11y ago
> 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.
- duaneb 11y ago
  > 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.
  - pcwalton 11y ago
    > 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?
    - duaneb 11y ago
      > 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....
      - pcwalton 11y ago
        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.
- Zikes 11y ago
  Are there GC'd languages that can get to 350us?
  - seiji 11y ago
    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. Related: http://www.evanmiller.org/why-i-program-in-erlang.html http://www.evanmiller.org/why-i-program-in-erlang.html
- bbrazil 11y ago
  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.
- cwzwarich 11y ago
  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.
  - iofj 11y ago
    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.
    - proveanegative 11y ago
      Is there an Azul equivalent for SmallTalk?

0xdeadbeefbabe 11y ago

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 https://twitter.com/rob_pike/status/618357610287226880

Zikes 11y ago
Ha! https://github.com/robpike/nihongo https://github.com/robpike/nihongo

Coding_Cat 11y ago

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

BinaryIdiot 11y ago

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.

Rapzid 11y ago

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