Cool, but I'd say Go is easy to learn. You can power through the spec, read Effective Go, figure out the go tools and GOPATH and be on your way. There's so little cruft. Go is limited in some ways, but the benefit is how simple it is.
With a language like JavaScript it can take a really long time to learn all the stupid stuff like when what this means. With Python it can also take a long time before you start having to figure out the various string representations, operator overloading and the crazy underscore variables. That kind of magical hidden complexity you see in other languages I don't think exists in Go, which makes it easy to learn.
With Go, I feel at least you can learn all that is Go in a week or so, and start building. Something like the "learn ruby/rails in 30 days" would never make sense to me given how easy it is to learn Go.
A lot of the expertise you see in Go comes from people who really know about the Go implementation. The way structs are represented in memory on different hardware, compilation optimization, the crazy stuff that most people are just not going to care about especially if they're going to run Go on some kind of cloud provider or in a vm.
I don't know much about Go but even a very small language like scheme can fuel quite a lot of screencasts if you put your mind to it. And Go is huge compared to a lot of scheme implementations.
It's not so much about learning all the syntax of the language on its own (which is useless and boring) but rather about how using the language to solve some real problems.
What I've learned about learning is that it's a very personal thing. People learn their way, not the way you think is the "best" way (and I mean the collective you, not you personally). Which is the best way to get started learning something? The way that you are comfortable with and the way that you see yourself continuing the learning process.
The commentary in the channel one is a bit off. With size 1+ it's a buffered channel and as such you could do what's shown in a single goroutine without blocking:
package main
func main() {
c := make(chan bool, 1)
c <- true
println(<-c)
}
It'd be unbuffered if there were no holding space, i.e. make(chan bool, 0) or simply make(chan bool)†. Cool project though - subscribed.
---
† Yes, built-in functions get not only generics privilege, but overloading too. It's evidently not as pitchfork-worthy.
I sort of found it ugly, before getting used to the syntax. A lot of the feeling of ugliness of a code comes from the unfamiliarity of the syntax.
I had the same problem with Rust, especially with the lifetime syntax; all these ' in random places just made a feeling of unevenness. But when your brain starts to have a deeper understanding on the construct, it processes things differently and the structure of the code comes at you in a clear way (when the code itself is not some crap by itself, of course). Beautiful code is clear code.
It's nowhere near as "elegant" as most scripting languages, and not nearly most of the purely functional languages, but I think it's better than /$C(++)?^/.
First of all thanks for making this - I'm definitely interested in go, and resources like this really help people like me to get started writing little programs. I watched the first screencast with the http request and I had a quick question:
When doing the http request, I notice you had to check explicitly for errors in three separate places. As a guy coming from mostly a node background, I'm certainly accustomed to having to handle error checking at multiple points in async code, but usually I'll use promises to propagate the error down the chain and handle any errors that occurred at a single point. This is a really elegant way to handle errors and makes some potentially super ugly async code really clean.
Is the standard way to handle errors in async code in go what you did in this screencast, or is there a more elegant way to do it in go that you just haven't covered yet?
Some of us still use them.. incredibly useful for not having to check back all the time. Also, with a properly specified enclosure can pull down the video separately which is handy.
Or is the new trick to not have RSS and just grab email addresses? Bit of a shame if that's the case.
With a language like JavaScript it can take a really long time to learn all the stupid stuff like when what this means. With Python it can also take a long time before you start having to figure out the various string representations, operator overloading and the crazy underscore variables. That kind of magical hidden complexity you see in other languages I don't think exists in Go, which makes it easy to learn.
With Go, I feel at least you can learn all that is Go in a week or so, and start building. Something like the "learn ruby/rails in 30 days" would never make sense to me given how easy it is to learn Go.
A lot of the expertise you see in Go comes from people who really know about the Go implementation. The way structs are represented in memory on different hardware, compilation optimization, the crazy stuff that most people are just not going to care about especially if they're going to run Go on some kind of cloud provider or in a vm.