This was exactly how I did it. The Effective Go part took me longer, since I actually jumped into porting a couple of small ruby libraries I picked (not mine, just ones I was familiar with) so that had me jumping to and from the book to the terminal/editor, so it probably took me like 5 days to port both libraries into Go code that I was happy with.
After that I had also read enough online to be familiar with the tools and the environment. Go is a really small language, but the ecosystem is rich.
You can have them try prototyping stuff on Go on the second week, trying some libraries, examining some existing Go code and that's it
There are good "XX" programmers, but I'd say that they're mostly good programmers and not tied to a specific language. Yeah, there are some niches where someone who's great at that niche may not be so good at other places (front-end, or maybe performance critical programming, or even things like COBOL or Java)
You can learn the syntax and be proficient with linear code in a couple of days but not for the parallelism part. Getting a feeling of good patterns with goroutines and channels takes a couple of tries before it becomes right.
Comments
How to train a new employee on Go: Day 1: complete the tour - http://tour.golang.org/ and read "How to Write Go Code" http://golang.org/doc/code.html
Day 2-3: read Effective Go - http://golang.org/doc/effective_go.html
Take a whole week, if you feel it is necessary.
This was exactly how I did it. The Effective Go part took me longer, since I actually jumped into porting a couple of small ruby libraries I picked (not mine, just ones I was familiar with) so that had me jumping to and from the book to the terminal/editor, so it probably took me like 5 days to port both libraries into Go code that I was happy with.
After that I had also read enough online to be familiar with the tools and the environment. Go is a really small language, but the ecosystem is rich.
Yeah, pretty much
You can have them try prototyping stuff on Go on the second week, trying some libraries, examining some existing Go code and that's it
There are good "XX" programmers, but I'd say that they're mostly good programmers and not tied to a specific language. Yeah, there are some niches where someone who's great at that niche may not be so good at other places (front-end, or maybe performance critical programming, or even things like COBOL or Java)
You can learn the syntax and be proficient with linear code in a couple of days but not for the parallelism part. Getting a feeling of good patterns with goroutines and channels takes a couple of tries before it becomes right.