Seems to be a lot of drama around dep. I don't like the way that rsc handled that situation at all (he would have been better not pretending to consult, and not trying to bring dep into the fold as a semi-official experiment). Calling it an official experiment and holding meetings with Sam made it seem like there would be significant input from the dep team, but that never happened. So lessons to learn for everyone, but give the structure of the Go team and Russ's place in it, it seems unlikely dep has a significant future.
Not sure I understand the need for this - if you are using containers it should be for instances which can die and you don't care what happens to them after. People sometimes put stuff in containers that they shouldn't (document storage, databases), which would be better hand-managed or using a central service for.
I’ve been working with Node.js for many years and then with Go within my latest projects.
Seems unlikely to be a comprehensive overview if written by someone who has mostly used node.js (for many years), and doesn't cite background in other languages as well. Still interesting to hear what other developers think on coming to the Go language, but this is just one perspective, hardly a comprehensive overview as the title claims.
See also https://speakerdeck.com/andrestc/understanding-go-memory-allocation-gophercon-uk
Sounds like a very minor release for a bug fix
Seems to be a lot of drama around dep. I don't like the way that rsc handled that situation at all (he would have been better not pretending to consult, and not trying to bring dep into the fold as a semi-official experiment). Calling it an official experiment and holding meetings with Sam made it seem like there would be significant input from the dep team, but that never happened. So lessons to learn for everyone, but give the structure of the Go team and Russ's place in it, it seems unlikely dep has a significant future.
This is a little thin - might be better as a blog post explaining what it is doing and why you use it?
Not sure I understand the need for this - if you are using containers it should be for instances which can die and you don't care what happens to them after. People sometimes put stuff in containers that they shouldn't (document storage, databases), which would be better hand-managed or using a central service for.
Love it - nice to see so many jobs for Go developers popping up. Where did you get all the jobs?
This should be really good for the go project I think.
Gorilla is missing.