I have really been enjoying Go, except for the built-in templating library. It's a wart on the standard library IMO.
The template declaration and invocation hierarchy seems unnecessarily complex and is almost 100% undocumented. It just hurts my brain and doesn't make any sense to me in comparison to jinja, whatever jekyll uses, etc.
It has very very poor documentation. Some docstrings are not a replacement for actual documentation when your approach is that unorthodox.
And it doesn't produce any error messages or warnings when you do something wrong - just renders a completely blank template.
EDIT: to be clear, my beef is with the template hierarchy, poor docs, and lack of errors/warnings, not with the general capabilities of the library, which are quite complete.
Interesting! I would say that the template library is one of the main reasons I reach for Go. If you want to have a microservice with a useful human-readable status page that tells the operator all about the application's internals, it is a snap in Go, while in C++ you'll be pulling your hair out.
True, and it is nice to have the capabilities in the stdlib. I just don't like the hierarchy setup, poor docs, and lack of errors/warnings when you get it wrong.
I guess I am just used to Python where there are 1-2 all-star 3rd party packages for each use case that the community tends to coalesce around. Rust appears to be heading in a similar direction.
Since Go has so much web/http stuff baked in, it is more likely that must people just stick with the stdlib approach, even if it's a bit of a PITA.
I also had hard times with built-in templating library for Go. That's why I created quicktemplate [1]. Usually it is much easier and natural to write templates in quicktemplate comparing to built-in templating library. As an additional benefit, quicktemplate templates work much faster (10x and more) than standard Go templates. The only downside that quicktemplate templates must be pre-compiled to Go code before building the app.
I love using text/template directly for codegen. Its really easy in my experience to create sophisticated tools using it + some go functionality. The trick is learning what gen problems are best solved in text templates and whats best solved in go functions. A big advantage of using text/template for codegen is you can just write the code you want to generate and it looks like real go code. Really easy to maintain compared to AST-style codegen.
Sounds similar to my use case. Two snags to work around when generating Go source:
1. The {{}} pairs confuse editor syntax coloring (in emacs, anyway).
2. Expansions that introduce or drop line breaks will cause the runtime/dlv to report line numbers that disagree with the pre-gen source you need to correct.
Not specifically Go related, but I am consistently annoyed that Helm's templating is a _very_ thin abstraction over Go's templating which has many drawbacks in that context.
The template declaration and invocation hierarchy seems unnecessarily complex and is almost 100% undocumented. It just hurts my brain and doesn't make any sense to me in comparison to jinja, whatever jekyll uses, etc.
It has very very poor documentation. Some docstrings are not a replacement for actual documentation when your approach is that unorthodox.
And it doesn't produce any error messages or warnings when you do something wrong - just renders a completely blank template.
EDIT: to be clear, my beef is with the template hierarchy, poor docs, and lack of errors/warnings, not with the general capabilities of the library, which are quite complete.