Personally, I use the rule of three. If it's copied three times, refactor it into some form of dependency. At that point, you should understand the use case, and should be able to create a reasonably designed API.
When doing this, be wary of what a friend of mine calls "misfactoring", an example of which being where you take three very similar, very readable bits of code and convert them into a single, parameterized mess that isn't understandable at all.
Rob Spike sounds like his alter ego, where he goes around giving talks on how duck typing is the way to go, and the top goal of a programming should be to express yourself in as few keystrokes as possible.
Any time you managed to get a response you must close the body via a defer resp.Body.Close()
And if you're using json.Decoder on the response body then it's worth noting that if you know you're only receiving a single JSON object then draining the remainder of the body will allow connection re-use as otherwise the connection will be closed and not re-used: https://github.com/google/go-github/commit/e0ff7111b024fda99...
- Go is a simple language. Going back to Python, I sometimes wish the language was a bit less batteries-included. (Incidentally, I've started to enjoy Lua a lot)
- Go's compiler is fast. It's slowed down a bit starting with 1.5 as they rewrote the core compiler in Go, but apparently 1.7 will reclaim much of that speed. In 1.5, I could compile and run with `go run mything` faster than it would take to spin up ipython.
- I've come to appreciate interfaces much more than classical OOP.
- The ecosystem is great.
The Bad:
- I hate GoDoc. I tried to like it, but it's essentially a list of function signatures with a near complete absence of examples or clear instructions. The documentation culture in Python is much better, IMHO.
- Channels are kinda slow. They're fast enough for almost anything network-related, but you should still use them conservatively.
The Different:
- Error handling in Go is the complete antithesis of error handling in Python
- `panic` is not `raise`. Donc use panic/recover for flow control.
- Blocking calls are perfectly okay.
A few suggestions:
- WRT interfaces, it's generally good to accept interfaces as function arguments wherever practical. Conversely, it's generally good to return concrete types from function calls, wherever practical. (See: https://youtu.be/29LLRKIL_TI)
- Go excels at networking. Use Go instead of Twisted/asyncio and I think you'll be convinced.
I agree with most everything you said; I just wanted to add my $0.02 to the remainder:
> I hate GoDoc. I tried to like it, but it's essentially a list of function signatures with a near complete absence of examples or clear instructions. The documentation culture in Python is much better, IMHO.
Just to give the opposite opinion, the nice part of godoc.org is that you get all the information in a consistent format in one place, and you can write documentation without needing to know Sphinx in all its complexity. Also, godoc.org is automatic--you don't need to publish anything yourself. I'm especially frustrated by documentation in Python because half the time all of the documentation for a given library is dumped onto one massive page, making it difficult to know if I'm looking at sqlalchemy.sql.select() or sqlalchemy.expression.Select.select() or sqlalchemy.sql.schema.Column.select() or etc. ReadTheDocs is great for libraries that use it, but there are too many that don't.
> Channels are kinda slow
They're still very fast for someone coming from Python.
1. GoDoc is actually great as a reference (i.e.: as Go's answer to Python's docstrings). I suppose I'm instead yearning for someone to hold my hand with regards to how I'm supposed to compose module primitives together, but that's admittedly a tutorial, not a docstring. So that said, I do like the Python community's insistance on comprehensive docs/tutorials, and I think the Go community needs more of that.
2. Very fast if you come from python, and fast enough if you're doing IO-bound stuff ... still slow if you're trying to do CPU-bound stuff.
Yes. It won't replace Python, but it's a good addition to the toolbox.
- It's high level enough you won't find yourself writing excessive (i.e. Java) amounts of boilerplate. But the corollary is that there much more boilerplate in Go than Python.
- It's fast enough to blow away Python for most network based usages.
- There's enough metaprogramming capabilities to make some really clever code. The downside is that there's enough metaprogramming capabilities to make some really clever code.
- You'll dig the distribution method of Go programs when compared to Python.
Your comment is pretty much the argument I offer when discussing Go with friends and colleagues who are skeptical of it.
I tell them to think of it as a tool in your arsenal, rather than the toolbox that carries everything you need. You will write far less boilerplate than Java, silly fast for certain network usages,and Goroutines have saved me quite a few headaches.
With that said, it is still pretty new. But it is a great tool to have.
> - There's enough metaprogramming capabilities to make some really clever code. The downside is that there's enough metaprogramming capabilities to make some really clever code
Interesting. My chief criticism of Python (as a Python dev) is that Python has too much metaprogramming capabilities, and people always write code that is more clever than necessary. I find that Go's culture seems to value doing simple things unless absolutely necessary. In one case, a recent Ruby->Go convert made a middleware library called Martini that leaned heavily on reflection, and the community's response was something like, "This is neat, but this seems too clever to be idiomatic", and the developer turned around and built Negroni, which is (I hear) more idiomatic and less clever.
I like Go but I get an uncomfortable culty-vibe from this posting. Also, if we could just title our blogs with "Interesting, Relevant, Engaging" so everyone would read them would be so much easier.
45 comments
[ 3.4 ms ] story [ 88.6 ms ] threadI like this but how do you protect yourself against growing into a lot of copying?
https://blog.golang.org/generate
The proverbs are based on this awesome talk by Rob Spike: https://www.youtube.com/watch?v=PAAkCSZUG1c
And for new proverb ideas, you can open an issue here: https://github.com/go-proverbs/go-proverbs.github.io/issues
And if you're using json.Decoder on the response body then it's worth noting that if you know you're only receiving a single JSON object then draining the remainder of the body will allow connection re-use as otherwise the connection will be closed and not re-used: https://github.com/google/go-github/commit/e0ff7111b024fda99...
I just did some Hackathons and tutorials and have a totally different understanding of what programming can be.
You may find their advice useful regardless of their intent.
Personally I don't have enough time or energy to determine someone's intentions, I just position myself to be guarded against ill-intent.
The Good:
- Go is a simple language. Going back to Python, I sometimes wish the language was a bit less batteries-included. (Incidentally, I've started to enjoy Lua a lot)
- Go's compiler is fast. It's slowed down a bit starting with 1.5 as they rewrote the core compiler in Go, but apparently 1.7 will reclaim much of that speed. In 1.5, I could compile and run with `go run mything` faster than it would take to spin up ipython.
- I've come to appreciate interfaces much more than classical OOP.
- The ecosystem is great.
The Bad:
- I hate GoDoc. I tried to like it, but it's essentially a list of function signatures with a near complete absence of examples or clear instructions. The documentation culture in Python is much better, IMHO.
- Channels are kinda slow. They're fast enough for almost anything network-related, but you should still use them conservatively.
The Different:
- Error handling in Go is the complete antithesis of error handling in Python
- `panic` is not `raise`. Donc use panic/recover for flow control.
- Blocking calls are perfectly okay.
A few suggestions:
- WRT interfaces, it's generally good to accept interfaces as function arguments wherever practical. Conversely, it's generally good to return concrete types from function calls, wherever practical. (See: https://youtu.be/29LLRKIL_TI)
- Go excels at networking. Use Go instead of Twisted/asyncio and I think you'll be convinced.
> I hate GoDoc. I tried to like it, but it's essentially a list of function signatures with a near complete absence of examples or clear instructions. The documentation culture in Python is much better, IMHO.
Just to give the opposite opinion, the nice part of godoc.org is that you get all the information in a consistent format in one place, and you can write documentation without needing to know Sphinx in all its complexity. Also, godoc.org is automatic--you don't need to publish anything yourself. I'm especially frustrated by documentation in Python because half the time all of the documentation for a given library is dumped onto one massive page, making it difficult to know if I'm looking at sqlalchemy.sql.select() or sqlalchemy.expression.Select.select() or sqlalchemy.sql.schema.Column.select() or etc. ReadTheDocs is great for libraries that use it, but there are too many that don't.
> Channels are kinda slow
They're still very fast for someone coming from Python.
1. GoDoc is actually great as a reference (i.e.: as Go's answer to Python's docstrings). I suppose I'm instead yearning for someone to hold my hand with regards to how I'm supposed to compose module primitives together, but that's admittedly a tutorial, not a docstring. So that said, I do like the Python community's insistance on comprehensive docs/tutorials, and I think the Go community needs more of that.
2. Very fast if you come from python, and fast enough if you're doing IO-bound stuff ... still slow if you're trying to do CPU-bound stuff.
WRT point #2, I like Gringo a lot: https://github.com/textnode/gringo
- It's high level enough you won't find yourself writing excessive (i.e. Java) amounts of boilerplate. But the corollary is that there much more boilerplate in Go than Python.
- It's fast enough to blow away Python for most network based usages.
- There's enough metaprogramming capabilities to make some really clever code. The downside is that there's enough metaprogramming capabilities to make some really clever code.
- You'll dig the distribution method of Go programs when compared to Python.
I tell them to think of it as a tool in your arsenal, rather than the toolbox that carries everything you need. You will write far less boilerplate than Java, silly fast for certain network usages,and Goroutines have saved me quite a few headaches.
With that said, it is still pretty new. But it is a great tool to have.
Interesting. My chief criticism of Python (as a Python dev) is that Python has too much metaprogramming capabilities, and people always write code that is more clever than necessary. I find that Go's culture seems to value doing simple things unless absolutely necessary. In one case, a recent Ruby->Go convert made a middleware library called Martini that leaned heavily on reflection, and the community's response was something like, "This is neat, but this seems too clever to be idiomatic", and the developer turned around and built Negroni, which is (I hear) more idiomatic and less clever.
The best parts:
* Static typing without much ceremony.
* Incredibly small memory footprint.
* on-par performance with Java without me being forced to write Java.
* Hella easy to deploy, one binary that contains everything. Runtime + GC + app code.
I.e. write "Golang" instead of "Go"