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.
Wow this looks pretty dense, but there’s some really good detail here about all the stuff that goes on under the hood when you listen and serve, which I think remains a mystery to most web developers. Can’t wait to see the video.
Some of these claims are a bit over the top. How could it possibly be faster than bare metal? All in memory and cached when talking to external services perhaps? It just seems a little too good to be true. Perhaps one day we will all write services/functions that talk to each other over a bus like this though, it definitely feels to me like there is something in all this serverless hype.
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.
Wow this looks pretty dense, but there’s some really good detail here about all the stuff that goes on under the hood when you listen and serve, which I think remains a mystery to most web developers. Can’t wait to see the video.
Some of these claims are a bit over the top. How could it possibly be faster than bare metal? All in memory and cached when talking to external services perhaps? It just seems a little too good to be true. Perhaps one day we will all write services/functions that talk to each other over a bus like this though, it definitely feels to me like there is something in all this serverless hype.
Great to see how to use the tracer, I've never used this. And who doesn't love a Mandelbrot set!