3. Devise some useful side project I could build with the language. Don't just go try to build them.
4. Build a couple of tiny utilities in the language.
5. Build something ambitious --- as in, something that would be ambitious even in my wheelhouse languages.
6. Reread online material about style, refactoring, libraries, &c --- I can't appreciate these fully or retain them until I've completed the preceding steps.
So, for Golang, I did:
1. Slurp up all the "what makes Golang awesome" stuff, read HN threads, &c.
2. Read Effective Go.
3. Decide "this would be great for building a large-scale web crawler backend"; gears start turning on how the different parts of the language would mesh for me.
4. Build a TLS proxy, a simple hex-dumping plugboard proxy, a CA library to do on-demand certificate generation.
5. Build an emulator for the TI MSP430 CPU and bootstrap it to the point where I can compile mspgcc code and run it on the emulator.
6. Read every blog post on the Golang site, start paying attention to Golang threads on HN and chiming in.
Step #6 is the step I'd want to be at before asking questions on the project's IRC channel.
I could break out Ruby, Python, Tcl, and C++ into the same set of steps over the past 10 years (my "native tongue" is C).
This is just how I do things, not necessarily the best way to do it. Also: when I'm learning, I favor a sharply NIH style --- I actually try to avoid fancy libraries, especially for stuff like Golang and (at the time I learned) Ruby, where the language is "hot" and the ecosystem is full of stuff that might not last. I'm worried about doing what Jamis Buck did and introducing dependency injection into Ruby, and then having to waste time undoing that.
I have in the back of my head 3-4 fairly ambitious projects I've queued up for the purpose of learning, say, Clojure or F#.
2. Read tutorials.
3. Devise some useful side project I could build with the language. Don't just go try to build them.
4. Build a couple of tiny utilities in the language.
5. Build something ambitious --- as in, something that would be ambitious even in my wheelhouse languages.
6. Reread online material about style, refactoring, libraries, &c --- I can't appreciate these fully or retain them until I've completed the preceding steps.
So, for Golang, I did:
1. Slurp up all the "what makes Golang awesome" stuff, read HN threads, &c.
2. Read Effective Go.
3. Decide "this would be great for building a large-scale web crawler backend"; gears start turning on how the different parts of the language would mesh for me.
4. Build a TLS proxy, a simple hex-dumping plugboard proxy, a CA library to do on-demand certificate generation.
5. Build an emulator for the TI MSP430 CPU and bootstrap it to the point where I can compile mspgcc code and run it on the emulator.
6. Read every blog post on the Golang site, start paying attention to Golang threads on HN and chiming in.
Step #6 is the step I'd want to be at before asking questions on the project's IRC channel.
I could break out Ruby, Python, Tcl, and C++ into the same set of steps over the past 10 years (my "native tongue" is C).
This is just how I do things, not necessarily the best way to do it. Also: when I'm learning, I favor a sharply NIH style --- I actually try to avoid fancy libraries, especially for stuff like Golang and (at the time I learned) Ruby, where the language is "hot" and the ecosystem is full of stuff that might not last. I'm worried about doing what Jamis Buck did and introducing dependency injection into Ruby, and then having to waste time undoing that.
I have in the back of my head 3-4 fairly ambitious projects I've queued up for the purpose of learning, say, Clojure or F#.