17 comments

[ 3.8 ms ] story [ 45.6 ms ] thread
Nice overview. Somewhat frustrating to see non-gofmt'd code examples. Fix that up :)
(comment deleted)
None of the links work in the embedded version, but if you download the PDF they're fine.
18k lines? Does that seem high to anyone else? Or am I missing something important?
It is high. Probably includes code site,docs etc.
High compared to what?

It's just the output of

    wc -l `find microcosm/ -name *.go`
so is really just a rough indication of the size of the project.
Compared to the amount of work that needs to be done for this project to function.
In that case, I don't know a number that can be used for that comparison. 18k is the total number of lines in the source code files; the SLOC will be different.

In hindsight, I should've left this number out. It was intended to give background to the overall program size, but it's a small detail that shouldn't be the focus of this discussion.

Well, Go has been touted for lower lines of code.
My experience has been pretty similar: Go is perfect for building high performance APIs. A lot of the library infrastructure is still in early stages.

One suggestion: Don't bog down your application server with serving static files (Slide 7. favicon and robots.txt). I put all of my css, js and image files in a /static sub-directory and configured nginx to serve any URL starting with /static without hitting my go-server.

Thanks for pointing that out. The static routes in the talk are just for illustration -- we use nginx to serve them in production.

One thing I haven't touched on at all is html template rendering, something I'd like to take a look at in detail at some point.

Would like to hear more about your experience with Go -- is there a writeup somewhere?

> My experience has been pretty similar: Go is perfect for building high performance APIs.

Like any native compiled language, it is just a matter of having the right set of libraries available.

Despite the overall ecosystem being rather small, the standard library and adjoining experimental packages are excellent. I wouldn't be surprised if go 1.2's stdlib would cover most of what Python's stdlib and Twisted can do.
Please call them web services or REST API, just API is confusing.
Maybe I missed it - but it would be really cool to see a large fragment of working code for some of the apis.