One thing Go won't do, is pull the variables out of the local scope into the string interpolation automatically. As I think easy string interpolation is an antipattern, and I'm comfortable having to feed values into the string formatter, I'm not upset, but you're not going to convince people with that.
As we slowly, oh so slowly, but surely move into languages where buffer overflows are not possible to write (or at least require scary excursions into some sort of "unsafe" package), easy string interpolations that allow the programmer to believe they don't have to think about the correct encoding of the value become the next most pressing security threat. Pretty much every "injection" is due to over-simplified string interpolation.
Unfortunately, if your string interpolation syntax is as easy is "This is an interpolated $string"... it's also wrong. Dead wrong, very wrong, run away screaming wrong wrong wrong! String interpolation is actually a very hard problem, and this must irreducibly manifest itself in the API. ImJasonH's example, while it isn't "string interpolation" in the Ruby/Perl/etc. sense, does involve using a template system with sensible escaping mechanisms... it's HTML-specific, though, but for HTML it's incredibly powerful and easy to use correctly. In fact Go's HTML templating is the most powerful and easy-to-use correct HTML templating system I've ever seen that isn't in Haskell. Presumably there are others out there, but I've seen a lot of the competition and most of them will sit by, twiddling their thumbs and whistling idly, while you put 100 injections of every kind into your HTML page.
My guess is Go will never grow this style of string interpolation, pretty much because it is so very, very frequently wrong. The way Go is already doing it is as easy as it can feasibly be, without encouraging wrongness.
I don't understand your claim that strong interpolation is wrong and the source of injection attacks, which are well known where building strings is much harder than interpolation. They come from not validating input data before use; requiring lots of work to build strings doesn't make it any more likely that people will do it safely.
"They come from not validating input data before use;"
I say they come from building APIs that don't require a statement of the correct way to escape output. Of course if your API doesn't require it, it doesn't happen.
Even the way you phrase it is dangerously wrong... validation of input and escaping of output are two entirely different things. I've implied this in my phrasing but let me spell it out, validation happens on the way in and is related to your local semantic domain (business rules, legal values of "an IP address" or "an email", etc), and escaping happens on the way out and is performed by the string "interpolation" or template system. If you've got them munged in your head into one concept, you're probably not writing correct code.
(For what it's worth, I see this formulation of the "root problem" more often than I see the right one. I really ought to write this up as a blog post.)
I'm looking out on the world and seeing what is there, which is a steaming mass of code that incorrectly manages strings. The fact that it is theoretically possible to correctly manage them is not that interesting of a fact, because observationally, it doesn't happen.
> Even the way you phrase it is dangerously wrong... validation of input and escaping of output are two entirely different things.
Yes, they are, but preventing injection attacks is the domain of the former more than the latter, and your suggestion that it is the other way is dangerously wrong. There are security risks addressed by the latter, but if you are relying on it to prevent injection attacks in the usual case [1], it means you are allowing untrusted unvalidated external data into your system and doing general processing on it and just trying to avoid a problem on output.
You prevent injection attacks by preventing malformed data from being injected into the system (at least, from such data making it past a validation component), not by allowing it freely into the system and trying to mitigate certain of its harms by escaping output.
Its true that proper escaping may help to limit injection attacks where imperfect validation has failed to prevent bad data from being accepted and processed, but even there more complicated APIs for string building don't make it more likely that people will do it right.
[1] the one place where it may be a proper mechanism for addressing injection attacks is when you are reporting the rejection of malformed input data, in which case you may have a legitimate need to use (some part of) the malformed data in the error report.
Nothing in Go pushes you towards using a domain specific templating language rather than Sprintf, only education (and culture) can do that.
So programmers _will_ use Sprintf, because it's one of the first things they'll have been taught, and Sprintf doesn't make dealing with encoding any easier or explicit than string interpolation.
Having string interpolation doesn't mean people can't or won't use domain specific templating languages, and not having it won't make it any more likely that they will.
As we slowly, oh so slowly, but surely move into languages where buffer overflows are not possible to write (or at least require scary excursions into some sort of "unsafe" package), easy string interpolations that allow the programmer to believe they don't have to think about the correct encoding of the value become the next most pressing security threat. Pretty much every "injection" is due to over-simplified string interpolation.
Unfortunately, if your string interpolation syntax is as easy is "This is an interpolated $string"... it's also wrong. Dead wrong, very wrong, run away screaming wrong wrong wrong! String interpolation is actually a very hard problem, and this must irreducibly manifest itself in the API. ImJasonH's example, while it isn't "string interpolation" in the Ruby/Perl/etc. sense, does involve using a template system with sensible escaping mechanisms... it's HTML-specific, though, but for HTML it's incredibly powerful and easy to use correctly. In fact Go's HTML templating is the most powerful and easy-to-use correct HTML templating system I've ever seen that isn't in Haskell. Presumably there are others out there, but I've seen a lot of the competition and most of them will sit by, twiddling their thumbs and whistling idly, while you put 100 injections of every kind into your HTML page.
My guess is Go will never grow this style of string interpolation, pretty much because it is so very, very frequently wrong. The way Go is already doing it is as easy as it can feasibly be, without encouraging wrongness.