Is template parsing a major bottleneck ?
What I know, most web apps need template parsing only at the beginning. Once initial startup is done, delivery of content is mostly constant.
What I know, most web apps need template parsing only at the beginning. Once initial startup is done, delivery of content is mostly constant.
For low traffic efficacy doesn't matter, for high traffic you should always cache the templates.
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.
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.
Really minor things like this add up
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...