When in Go, do as Gophers do
talks.golang.org
When in Go, do as Gophers do
1–10 of 93 posts
Re: When in Go, do as Gophers do
#2I've never known a language with so much discussion on why what you are doing isn't idiomatic as Go.
I'm enjoying using Go for the few small services I'm using it for but it seems that a language which has to constantly fight it's users to reinforce what it considers idiomatic has some core issues.
Re: When in Go, do as Gophers do
#3I've never known a language with so much discussion on why what you are doing isn't idiomatic as Go. I'm enjoying using Go for the few small services I'm using it for but it seems that a language which has to constantly fight it's users to reinforce what it considers idiomatic has some core issues.
this is especially true for everything related to error handling. I've never had to deal with a java codebase where exception were causing problems, but golang made me feel worrying about it from day 1. I really think they made the language a little bit too small.
Re: When in Go, do as Gophers do
#4I've never known a language with so much discussion on why what you are doing isn't idiomatic as Go. I'm enjoying using Go for the few small services I'm using it for but it seems that a language which has to constantly fight it's users to reinforce what it considers idiomatic has some core issues.
this is especially true for everything related to error handling. I've never had to deal with a java codebase where exception were causing problems, but golang made me feel worrying about it from day 1. I really think they made the language a little bit too small.
I think small is a good thing in languages for example the C programming language is very simple in the language but very powerful. Simplify Simplify Simplify.
Re: When in Go, do as Gophers do
#5Earlier quoted context omitted.
this is especially true for everything related to error handling. I've never had to deal with a java codebase where exception were causing problems, but golang made me feel worrying about it from day 1. I really think they made the language a little bit too small.
I think small is a good thing in languages for example the C programming language is very simple in the language but very powerful. Simplify Simplify Simplify.
Not that much if you leave out compiler specific extensions not part of ANSI C and library functions that are actually implemented in Assembly.
Re: When in Go, do as Gophers do
#6I've never known a language with so much discussion on why what you are doing isn't idiomatic as Go. I'm enjoying using Go for the few small services I'm using it for but it seems that a language which has to constantly fight it's users to reinforce what it considers idiomatic has some core issues.
this is especially true for everything related to error handling. I've never had to deal with a java codebase where exception were causing problems, but golang made me feel worrying about it from day 1. I really think they made the language a little bit too small.
If you have only worked in languages with exceptions, it's not surprising that you would struggle with Go's C-style error handling.
I've grown to prefer it, as exception handling typically boils down to "not my problem" in most code bases. Go forces you to think through each error condition, which is an unusual amount of effort for people who may not be accustomed to it.
Re: When in Go, do as Gophers do
#7Sad that this is still the way to test for interface implementations.
Re: When in Go, do as Gophers do
#8I found that I already do all of these as a result of reading through a lot of the Go standard library when I was learning it. One of the best ways to really learn a language is to read the standard library (the parts implemented in that language, anyway). That way you get a sense of the idioms used, but also understand the sometimes subtle trade-offs of common functions.
Re: When in Go, do as Gophers do
#9Unrelated to the core presentation. I wrote http://readcode.in/ to help with reading source code in a simple single page format. It really fits go code repositories as they are usually small. e.g. http://readcode.in/github.com/gorilla/mux
Re: When in Go, do as Gophers do
#10Earlier quoted context omitted.
this is especially true for everything related to error handling. I've never had to deal with a java codebase where exception were causing problems, but golang made me feel worrying about it from day 1. I really think they made the language a little bit too small.
If you have only worked in languages with exceptions, it's not surprising that you would struggle with Go's C-style error handling. I've grown to prefer it, as exception handling typically boils down to "not my problem" in most code bases. Go forces you to think through each error condition, which is an unusual amount of effort for people who may not be accustomed to it.
Go's error handling remains verbose, unsafe and error-prone compared to more modern languages which use return values for error signaling (Erlang, MLs, Haskell, Rust).
The problem is not that Go's error handling requires more thinking or efforts, it's that it is bad, and while that's an improvement from C's terrible error handling it's still nowhere near good enough, let alone good (unless you consider C's error handling to be good enough in the first place).