Go Proverbs: Simple, Poetic, Pithy
go-proverbs.github.io
go-proverbs.github.io
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
I like this but how do you protect yourself against growing into a lot of copying?
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 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.
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...
I.e. write "Golang" instead of "Go"