63 karma · joined September 10, 2010
I've read various articles including (but not limited to) tutorials, made a point of exploring a few open source projects and I've written a few thousand lines of Go. I enjoy writing Go, but I have a hard time so far figuring out if what I write is idiomatic.
One thing that the circle metaphor does add is nested groups, which I can see being important for a different set of use cases.
Also, the Octocat was not on the page that Google cached: http://webcache.googleusercontent.com/search?q=cache:SZgkdCZ...
My suggestion: start with native app development for the device that you own and use most. Run through a couple of beginner tutorials and write a few toy apps. This will give you a more solid foundation for making decisions. (I would not recommend using cross platform tool-kits until you understand the trade-offs.)
Then, I recommend that you build one of your ideas for the same device and release it. After releasing it, you can either move on to the next idea or port it for the other platform.
For example, you can certainly learn a few things by looking at what is in the distributed app package.
I found Play to be fairly intuitive and it matched my mental model pretty well. It was lightweight compared to Lift and the other Java frameworks I looked at. Play 2.0 seems to have made improvements in the areas I found weak in Play 1.x. i.e. modularity, Scala support (specifically for continuations)
Lift is a fairly heavy framework, but you can ignore big parts of it if you need to. In Lift it took me a while to grasp the HTML transforming concept, partly because the documentation seemed to out of date. It felt both cumbersome and elegant at the same time. Sadly I didn't get very far on the project so I have no idea how Lift has changed/improved since then.
Today I would choose Play in a heartbeat if it fit the parameters of my project.
Even if you ignoring the fact that he is paying for the data plan, the author mentions that he is paying "$0.019 per minute" for most outgoing calls within the U.S.
The most closed thing I can think of is when they only enabled their faster JS engine for the browser itself and not for apps. The next major release changed that, and it is not related to WebKit itself.