That's not the reason I use Clone() in this pattern. The main reason for the clone operation is convenience. The clone operation is on the already-parsed set of shared templates (base+partials in this example code). It provides the convenience of not having to specify the path to the base template and any paths to the partial templates needed by that page in the call to render().
There may also be a performance benefit too - I suspect that the Clone() operation is cheaper than re-parsing the base and any necessary partial templates in each render() call, but I've never benchmarked it, so I can't assert that with certainty.
As the author of this post, I can answer this question with a very clear "no".
There is an interesting side point though. I've been blogging about Go since 2013 (generally writing similar articles to this one) and from 2013 to 2025 I think just one post made the front page of HN. In 2026, all 3 posts I've written have.
My theory is that there's now fewer people spending the time to write original content. With LLMs and AI-generated instant answers in search, the incentive to write these kind of deep-dive articles is way less than it used to be, so maybe there's both less competition and more appreciation for it? That's my working theory at the moment anyway.
The kill of go-reload was to make sure background processes get cleaned up, but I suspect one of the kill or exit in the close function is superfluous.
Sure. Send the signal, the signal handler - custom or default - handles it. This works whether the signal comes from another process or its own process.
There may also be a performance benefit too - I suspect that the Clone() operation is cheaper than re-parsing the base and any necessary partial templates in each render() call, but I've never benchmarked it, so I can't assert that with certainty.