Many of your comments on this thread state that writing webapps in Go (SQL, etc) is not so difficult "once you know what you're doing." Could you elaborate on this? What should one know before attempting to use Go for such things?

Here's one possible example. At the top of this thread, there's a statement about how Go templates don't support inheritance-- embedding one template within another as Django and Jinja do[1]. I personally consider this a requirement, because the old school way of having headers and footers in separate templates is radically inferior.

Go doesn't offer a clear simple way to do this in their builtin template library. But it turns out, it really is possible to do it, as described in this thread on Stack Exchange[2]. I bookmarked that so that I can boil it down into some simple-to-reuse code if I ever bite the bullet and start using Go for the presentation layer on a major website. What they're doing there is a cool technique, but it's not simple to use out of the box.

1. https://sites.google.com/site/usfcomputerscience/django-temp...

2. http://stackoverflow.com/questions/11467731/is-it-possible-t...

the problem with html/template is that it's made for Go programmers. A good template language is one that's made for front end devs and designers. html/template tends to be painful in practice because it's too difficult for a non-gopher to use.

html/template is literally nothing more than an "HTML-safe" version of text/template, which is Go's arbitrary text template language. It's meant to be completely a drop-in replacement for text/template, and as such, its design does not give HTML output any special consideration, which an HTML-specific template language would.

I understand the point you're making - I just want to point out that Haml is explicitly designed for HTML, whereas html/template more or less "just happens" to be useful for HTML.

As for ERB, I'm not convinced that it is too different in this regard. I'm not much of a Rubyist, and I find it incredibly frustrating to use, but perhaps that's a matter of personal preference.

{text,html}/template have their warts - I literally started Jetpack because of an unusual html/template quirk I ran into that was tricky to debug. However, I don't think it's any worse than other template language in this regard (my main points of reference are Jinja2, ERB, Haml, and Scribble).

It is context aware, which is actually really awesome! It understands if it is in a tag, in a script, in quotes, in double quotes, in source, in css, in style and lots of stuff I am forgetting and does the custom escaping required to make it safe for that context. That is freaking magical.

The html/template package seems to address the use case, but it comes up short in several ways. One example is defining a site template with sections that are optionally specified in a page specific template.