4 ms·

I've written a fair amount of Go and his view is pretty consistent with my experience. Go has a good culture of doing things the simplest correct way and only t

I've written a fair amount of Go and his view is pretty consistent with my experience. Go has a good culture of doing things the simplest correct way and only that way. Rust is really interesting because of the stronger compile-time assurances and lighter footprint (looks like it'll be a good candidate for embedding into mobile apps), I'm learning it in the hopes that I'll be able to use it as an alternative to C for portable library code.

technological 12y ago
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 12y 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 12y ago
    In addition you can get some insight for the "why" questions by reading through their mailing lists (dev and nuts).
- Manishearth 12y 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 12y 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 12y 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.

technological 12y ago

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 12y 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 12y ago
  In addition you can get some insight for the "why" questions by reading through their mailing lists (dev and nuts).
Manishearth 12y 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 12y 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 12y 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.