Thoughts on Go after writing 3 websites
blog.kowalczyk.info
blog.kowalczyk.info
At the beginning it's frustratingly slow, as it always is when you learn something new, but if you know other C-like languages, picking up Go will be fast. You just have to put the time to learn standard library and Go way of doing some things.
I wrote a short script to automate generating the struct definitions, since I didn't want to generate the structs by hand. Go's reflection made this really easy.
1. It assumes all slices to be of type []interface{} by default, though oftentimes a more precise type is possible. (This is just a matter of looping through and determining the most specific type)
2. It only accepts valid JSON. Not a bug, but for example, the sample responses on the foursquare API documentation omit the (required) quotation marks around identifiers: https://developer.foursquare.com/docs/venues/venues (click "Try it Out"). That's a common problem which I'd like to fix eventually.
Anyway my point, in case you missed it, is that "GO" is not correct.
It also can decode directly into typed structures. An example from the documentation (you'll have to open the linked example): http://golang.org/pkg/encoding/json/#example_Decoder
Anecdotally, a typed version of JSON decoding is much nicer to work with.
How so? Considering that JSON isn't strongly typed.
Why is this nicer?
Let's say you are working with the Reddit API. You can, of course, do it the way you suggested, and just decode the result into an untyped object. However, I find this incredibly brittle. You end up with strings indexing into arrays all over the place.
On the other hand, when you decode into a Go struct, you use the regular dot syntax to access parameters. You can't misspell these or use the value inappropriately (trying to loop over a JSON number, for example). You can write comments on the fields to document what you expect various values to hold. It is nicer in the same sense that using classes is nicer than just using arrays for everything.
Another benefit is of course the improvement of performance. Accessing an string value in a JSON object by a key is the equivalent of a hash table lookup in Python or PHP. It is incrementing a pointer by a constant number in Go (assuming you use strongly typed decoding).
I'll say it again, Go's encoding/json can do what you want (the equivalent of json_decode). There are better alternatives available to users of that package, and the GP was discussing how to exploit one of those better alternatives without having to write the struct by hand (which I personally find a trivial one time cost).
Compiler telling you about a bug because you have a typo in your code (as opposed to blowing up at runtime, sometimes in a way that you won't notice) is also important.
Struct definition is also a documentation of your data. Another developer (or you a month from now) doesn't have to go back and re-read, say, Redit API docs. He (or you) can just re-read definition of the struct and know all the data that a given JSON request provides. That's nice.
An editor can parse the struct definition and give you auto-complete, which is also nice.
First, let me point out that we have moved on to a slightly different topic. The tools that json_decode gives you is available in Go (it would be syntactically awkward, out of a necessity born of Go being statically typed). An example: http://play.golang.org/p/OvshdY1oVQ
However, I would write it as follows http://play.golang.org/p/pODFi9Jrve. This is merely a different way of doing the same thing.
Now, to the topic that we are talking about is the claim that the latter is nicer. I was not comparing PHP and Go when I said that it was nicer (although I have some experience with PHP). I was drawing from my experience with working with JSON in statically typed languages. In particular, working with JSON in C++, Objective-C and Go. In all of these languages, the JSON libraries I used were essentially dynamically typed. I claimed merely that having the JSON library use reflection to deserialize into typed structures is nicer than using NSDictionary's various methods or maps in C++.
In PHP, the syntactic overhead of walking dynamic structures is obviously much lower than the languages I was thinking about, so that criticism is blunted when referring to that language. But I still believe there is some advantage there. A large part of what I find nicer about the latter is indeed the same reason I prefer static typing to dynamic typing. It is impossible to mistype the latter (try changing the ".Foo" to ".Fo" and trying to run the snippet). Consider that doing the equivalent in PHP will simply return NULL (I think), as it is really just doing a dictionary lookup. I fully admit that this is a static versus dynamic thing, not about JSON in particular.
As to the performance thing, I think you too easily discount the importance of low latency. But regardless, I was really comparing to Go's statically typed brethren. They essentially use hashtables for representing parsed JSON objects which is far less than ideal. Note that they don't employ the clever tricks that dynamic languages use. V8, for example, makes JS's objects (which are essentially hashtables) perform significantly better than a mere hashtable.
In pseudo-code-ish:
type FacebookUser struct {
ProfileID int
Name string
....
}
json.Unmarshal(response, FacebookUser)
json_decode($response);
json.parse response
It's certainly why I find it more appealing, anyway. Makes me feel more secure in my code.
Though you have to look at the package api yourself to decide whether it's running directly or not.
My point? These things came way before node.js, so no, node.js isn't the only one with a built in webserver.
The difference is node.js has a rather performant built in webserver (still, exeperience shows that a properly tuned gevent or netty beats a properly tuned node.js). The idea is that instead of spending time tuning these things, you can just wrap it in a uWSGI container, and let better tuned-out-of-the-box servers like nginx handle the webserving
I would be much more uncomfortable running on uWSGI than on net/http. As far as I can tell (https://github.com/unbit/uwsgi/blob/master/plugins/go/src/uw...) Go's uWSGI implementation is just a small wrapper over C code inside a dll.
It's not portable (support for cgo on Windows is extremely sketchy).
It also goes against common sense. Any code you can write in C, you can write in Go, except it'll be easier (Go is garbage collected, has built-in arrays, strings, hash tables etc.) and there's drastically smaller chance Go will have a security issues due to memory over-write.
It duplicates lots of net/http functionality.
net/http is well documented, well tested, reviewed by extremely knowledgeable people.
Most importantly, it is being used in production by me and many other people.
Finally, net/http gave me everything I needed to write my web applications. Before I would even considering using uWSGI (or anything else) someone would have to explain what exactly does it provide that is so indispensable for writing web apps.
Sadly me (and a lot of other people) need a lot more.
That is why the uWSGI project exists. Things like logging, clustering, statistics, multi protocol support, alarms, time events, request routing and blah blah are added to your app for free (and the funny thing is that you can tune lot of internals without rebuilding your app).
Obviously if not having windows support is a too much high price for you the discussion ends here :)
Obviously it depends on the average pageviews per user, but what's your gut feeling? Should $80 have been too expensive?
If you're paying that much, you've been taken for a ride. That's ridiculous.
I probably could have gotten away with paying $0 if I didn't care about the best performance.
App Engine is distributed. You get one front-end instance for free. The more front-end instances you spin up, the lower the latency for your requests (consider a fron-end instance a process, the more processes you have, the more requests you can handle in parallel, which lowers latency for each request).
All the money was spent on additional (3, I believe, front-end instances).
Was the price high? Yes, which is one reason I switched to a $60/month kimsufi server which hosts the blog and still has 99% of capacity free for other things.
It's possible I was over-paying. I'm not an App Engine expert. I picked the number of instances more on a gut-basis than a comprehensive analysis basis. I could afford it so it wasn't a big deal.
Also, you have to copy the assets (templates and such) and if you're deploying a new version of a web app, you don't just overwrite the binary. My script makes sure that if something goes wrong (i.e. a new version doesn't work or has a bug), it's easy for me to revert to previous version.
That being said, none of that implies that Go makes deployment harder (or easier, for that matter) than deploying code in other languages would be. It's pain in the ass but nothing that I couldn't solve in a day with a script written with Fabric.
For whatever it's worth, I think CGO is only needed for native DNS resolution. If you (cross-)compile with CGO_ENABLED=0, then net/* will fall back to a pure Go DNS resolver, for which the only requirement is a valid /etc/resolv.conf on the target system.
Isn't that the point of version control? Any DVCS makes that easy to do.
http://godoc.org/github.com/gorilla/securecookie http://godoc.org/github.com/gorilla/mux
Or on GitHub: https://github.com/gorilla