Exactly, I used django and jinja templates. Those two are feature rich. Golang template engine is mostly minimal with enough feature to do things.
The problem with Golang, most developers look for performance instead of the features. People who use python or ruby look for better features and ease of development. So, Golang engineers develop applications and libraries which doesn't help anyone.
Go template language has a nice context sensitive escape mechanism. But the syntax is kind of garbage and it's very limited when it comes to features ( no template inheritance, curb-some API for plugins ... ). Like everything in Go it gets you 50% there and but it's PITA to do something complex with it. Go is really bait+switch . You can get started fast but then you run into a vast amount of issues when it's time to deliver a professional product with std lib. It's true for testing,logging,writing web-apps, debugging and even concurrency. I hope the more Google rely on it, the more the maintainers will be pressured withing Google to fix its shortcomings.
I write Go professionally now and it's just not a productive language. The concepts are there, but the execution was frankly quite lazy and inconsistent.
Never panic in an external API, but closing closed channels and random number functions panic in the same way Java throws checked exceptions.
Generics aren't important, except for slices, maps, and channels which are generic.
When a program panics, it's saying that there is a fundamental problem with your logic. Closing closed channels and dividing by zero are both examples of those.
Complex json parsing is kind of bad too in go - and rather surprising for a modern vm/go based language. (I guess they really tried to go for c/c++ with go but why vm/gc)
Google will probably fix these things with time though, or so I hope - at the moment go seems like a conflicted language.
1. that requires parsing the template at compile-time (making it non-overridable at runtime) or the ability to generate executable code at runtime which break in NX-mandatory environment (e.g. appstore applications)
2. the runtime version may be much faster than the compile-time one, e.g. the rust Regex crate has both a runtime Regex structure and a regex! compiler plugin, the latter is currently significantly slower at runtime: https://github.com/rust-lang/regex#usage-regex-compiler-plug...
Yes, "compile/load/execute" can take longer than simply "eval". You have to consider amortized costs: how often do you need to recompile your template (or your regex)? Likewise, are you really going to override the template at runtime or is the variable part of the template already compiled as branches in the resulting code? Whatever needs to be dynamic can be dynamic while compiling as much as possible ahead of time.
For low traffic efficacy doesn't matter, for high traffic you should always cache the templates.