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.
Don't want to be that guy but it looks like inbred child between c, php and pascal.
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.
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.
However if I could offer a small critique, that currently the code is only legible with the video at fullscreen and not at all legible on a phone.
It would be nice if you used a smaller editor width of at 80 columns, and larger font, it would be much easier to read the code as you talk though it.
Thanks and I look forward to more videos!
package main
func main() {
c := make(chan bool, 1)
c <- true
println(<-c)
}
---
† Yes, built-in functions get not only generics privilege, but overloading too. It's evidently not as pitchfork-worthy.
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.
Thanks