4 ms·

Sorry for asking off topic question. What is good resource you suggest for understanding go memory management. For someone I am unable to understand from golang

Sorry for asking off topic question. What is good resource you suggest for understanding go memory management. For someone I am unable to understand from golang docs

rmcpherson 11y ago
The best place to start, if you haven't read it, is the documentation here: https://golang.org/ref/mem https://golang.org/ref/mem For more detailed information on the garbage collector improvements and roadmap for 1.5 and beyond, this document is the Roadmap and discusses improvements being made including a maximum of 10 ms STW out of every 50 ms. https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLovrHvvLhK_h0KN8woTO4/preview?sle=true https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLo... edit: fixed incorrect link
- hedgehog 11y ago
  In addition you can get some insight for the "why" questions by reading through their mailing lists (dev and nuts).
Manishearth 11y ago
The nice thing about Go is that you rarely have to think about memory management. Can you access the object? Then it exists! (even across threads) You should use locks for thread safety though. That being said from a Rust background I like to be able to know what's going on at the lower level and Go makes that harder, but that's not a major issue whilst programming.
- Manishearth 11y ago
  FWIW in Rust "Can you access the object? Then it exists!" is true too, however you have to wait for the compiler to reach a certain point to know that you indeed were allowed to access it[1], whereas in Go you can figure this out by looking at the code :) [1]Or internalize the borrow checker, which is something which eventually, automatically happens to all Rust programmers AFAICT. It actually spills out into other programming languages too so you get a nice involuntary mental tool to ensure safety in C++ :)
- JulianMorrison 11y ago
  For thread safety, you only want locks if your variable is shared. And even then consider using "sync.atomic" compare and swap operations instead. It's often possible to avoid sharing by passing discrete data around via channels. As a general rule, if it only has one owner, it's thread safe.

Sorry for asking off topic question. What is good resource you suggest for understanding go memory management. For someone I am unable to understand from golang docs

rmcpherson 11y ago

The best place to start, if you haven't read it, is the documentation here: https://golang.org/ref/mem https://golang.org/ref/mem For more detailed information on the garbage collector improvements and roadmap for 1.5 and beyond, this document is the Roadmap and discusses improvements being made including a maximum of 10 ms STW out of every 50 ms. https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLovrHvvLhK_h0KN8woTO4/preview?sle=true https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLo... edit: fixed incorrect link

hedgehog 11y ago
In addition you can get some insight for the "why" questions by reading through their mailing lists (dev and nuts).

Manishearth 11y ago

The nice thing about Go is that you rarely have to think about memory management. Can you access the object? Then it exists! (even across threads) You should use locks for thread safety though. That being said from a Rust background I like to be able to know what's going on at the lower level and Go makes that harder, but that's not a major issue whilst programming.

Manishearth 11y ago
FWIW in Rust "Can you access the object? Then it exists!" is true too, however you have to wait for the compiler to reach a certain point to know that you indeed were allowed to access it[1], whereas in Go you can figure this out by looking at the code :) [1]Or internalize the borrow checker, which is something which eventually, automatically happens to all Rust programmers AFAICT. It actually spills out into other programming languages too so you get a nice involuntary mental tool to ensure safety in C++ :)
JulianMorrison 11y ago
For thread safety, you only want locks if your variable is shared. And even then consider using "sync.atomic" compare and swap operations instead. It's often possible to avoid sharing by passing discrete data around via channels. As a general rule, if it only has one owner, it's thread safe.