A Mini-Guide to Google Golang and Why It's Perfect for DevOps
blog.bluematador.com
A Mini-Guide to Google Golang and Why It's Perfect for DevOps
1–5 of 5 posts
Re: A Mini-Guide to Google Golang and Why It's Perfect for DevOps
#2Just yesterday, I discovered their date parsing, which uses example based formats. It's pretty cool. Instead of the typical yyyy-mm-dd format nightmare, you would do 2006-01-02. The reference date is the key.
Re: A Mini-Guide to Google Golang and Why It's Perfect for DevOps
#3the thing i hate most about golang: no generics. the thing i love most about golang: super fast. Just yesterday, I discovered their date parsing, which uses example based formats. It's pretty cool. Instead of the typical yyyy-mm-dd format nightmare, you would do 2006-01-02. The reference date is the key. https://golang.org/pkg/time/#pkg-constants
Having said that, I would not complain if the concept of Ply (https://github.com/lukechampine/ply) becomes part of standard Go.
Re: A Mini-Guide to Google Golang and Why It's Perfect for DevOps
#4the thing i hate most about golang: no generics. the thing i love most about golang: super fast. Just yesterday, I discovered their date parsing, which uses example based formats. It's pretty cool. Instead of the typical yyyy-mm-dd format nightmare, you would do 2006-01-02. The reference date is the key. https://golang.org/pkg/time/#pkg-constants
Generics have their use cases, but in general they are overrated. Especially in (but not limited to) the DevOps area, I bet that 99% of the code needs no generics at all. Having said that, I would not complain if the concept of Ply ( https://github.com/lukechampine/ply ) becomes part of standard Go.
Re: A Mini-Guide to Google Golang and Why It's Perfect for DevOps
#5the thing i hate most about golang: no generics. the thing i love most about golang: super fast. Just yesterday, I discovered their date parsing, which uses example based formats. It's pretty cool. Instead of the typical yyyy-mm-dd format nightmare, you would do 2006-01-02. The reference date is the key. https://golang.org/pkg/time/#pkg-constants
Generics have their use cases, but in general they are overrated. Especially in (but not limited to) the DevOps area, I bet that 99% of the code needs no generics at all. Having said that, I would not complain if the concept of Ply ( https://github.com/lukechampine/ply ) becomes part of standard Go.
Ply looks interesting, but still lacking for my particular use case.