Here's my high priority feature list right now:

Gzip support, hashes for serving static assets, multi-user support, support for all of the Ghost theme helpers, MySQL, Postgres, and Google App Engine support.

So consider this a vote for "static site support". If I were to express that as a requirement it would be something like "Site is served off a set of static pages that were generated on demand as the content on them or around them changed."

Wrote my own engine for exactly this reason.

All python, no templates and only one imported module (markdown) which I'm going to use pythons (why not in the first place?). I concur with the idea. Whole blog is about 1.4Mb of text. Images are hosted so it's AUD3.5/month to host the blog + domain.

It's not Ghost compatible. I based my template on Jeckyl. That is YAML front-matter followed by markdown. All contained in text files. It's a bit slot at the moment but works a charm.

What format are you following?

* hotdog (binary) -> site (worked there)

* blosxom (perl) -> site

* perl -> TT -> ftp -> site

* python -> webpy -> appengine -> site

now * python -> markdown -> ftp/ssh -> site

future

* [some back-end language/Rpi] -> js [front-end/iPad] -> [some transport layer] -> site

I'm trading simplicity for speed and turn-around. The tool-chain is all cli, vim + browser. At some stage soon I'll write either an api/server to allow a simple interface to speed up process.

The basic ideas are based on Dave Winer and Scripting.com

If it doesn't yet support multi domain will it ever?

I'll add that to the list as well. I think that might be a useful feature.

https://en.wikipedia.org/wiki/Memory_safety

Memory safety is enforced in Go via best practices–like C and C++ ecosystems. However because of gc and channels race conditions happen less often in Go but there's no explicitly tooling to prevent them from happening:

http://research.swtch.com/gorace

That way you would be catching a lot more code issues then just unused imports, variables etc.

Couldn't you use panic/recover locally, inside functions - just for having a single error handling code?

Rob Pike has written ideas here on how to clean up error handling if-blocks: http://blog.golang.org/errors-are-values

The panic/recover idiom is extremely useful in parsers. For example, Go's JSON decoder: http://golang.org/src/encoding/json/decode.go

Panic/recover are usually meant to catch "coding" and "assertion"-type errors (null pointers, array overflows, etc), not runtime errors. The latter is what the "error" values are used for.

"gonads" would be my choice of name for this library.

http://www.infoq.com/presentations/functional-pros-cons?utm_...

https://github.com/dagoof/failure

[Docs] https://godoc.org/github.com/dagoof/failure

I don't know why so often, the immediate reaction to legitimate criticism of this wart in Go is to argue against exceptions, even when nobody has even brought up exceptions as an alternative.

I agree that, probably universally, the people who fervently argue for either exceptions or explicit Go-style error handling don't know about Maybe/Either/Result. Then again, all this is pretty much impossible to replicate in Go.

That said, even something as simple as errors being literal values that you can pattern match on is surprisingly versatile. Exceptions don't necessarily have to be awful weights that spill down all over the call stack, either. They can be distilled to a more basic catch/throw mechanism for shuffling around error properties and states.

What I've seen a lot of is swallowing of errors. For example readFromFile().orElse("") where there is no indication from an outsider that anything wrong happened. A cool feature would be logging any instance of when orElse was the result.

Would be curious how these work in other languages.

Personally I find them essential in particular for larger codebases. They allow for centralised, consistent error handling behaviour. For example paging application support teams only for certain types of errors.

And you can always emulate explicit error recovery with exceptions. So what is so bad about having the flexibilty to accomodate different styles of error handling.