I balked a little when the article refers to format strings as "string interpolation" but there's multiple comments here running with it. Am I out of date and we just call that string interpolation these days?
I also found this very confusing:
> When updating a map inside of a loop there’s no guarantee that the update will be made during that iteration. The only guarantee is that by the time the loop finishes, the map contains your updates.
That's totally wrong, right? It makes it sound magical. There's a light explainer but I think it would be a lot more clear to say that of course the update is made immediately, but the "range" iterator may not see it.
I think people get bizarrely hung up on the tiny details of this between languages... but then, I think that extensive use of string interpolation is generally a code smell at best anyhow, so I'm probably off the beaten path in more than one way here.
To write? Maybe so. Now try to modify it. Enjoy matching quotation marks and juggling commas. It's awful, which is why everybody uses fmt.Sprintf() instead.
String interpolation is a must have these days, I wish the Go devs would wise up to that fact.
Syntax highlighting fixed that for me something like 20 years ago.
But then, like I said, I consider extensive use of this a code smell at best. If you're doing this often enough that this is an actual problem for you, then you're probably doing something wrong. Most uses of string interpolation I see are wrong somehow, and that wrongness is often a security issue.
It's used all the time in logging. The nature of this also means it's more likely than critical code to end up not doing what you expect, right up until you need to look at logs to debug a live issue. String interpolation is just vastly superior at this compared to format strings.
Format strings also have a history* of crashing or worse and have historically been a very legitimate security concern by themselves. At least Go didn't inherit that.
*Well, still-present if you still use the bad functions in C or C++.
Which I would consider one of the code smells in question, because logging should be structured anyhow.
I understand there are a lot of code bases in the world that already exist that lack structured logging. That may make it "all things considered the right engineering decision to not fix this architectural flaw today", but it doesn't make it not a code smell or an architectural flaw.
Indeed, I have always heard such techniques as "string formatting" while built-in-to-the-language local-variable implicit string formatting sugar syntax is the thing I've heard called "string interpolation".
In Python, calling "{}".format(x) is string formatting, while string interpolation would be to use the language feature of "f-strings" such as f"{x}" to do the same thing. As far as I know, go doesn't have string interpolation, it only has convenient string formatting functions via the fmt package.
Basically, if you format strings with a language feature: interpolation. If you use a library to format strings: string formatting.
I think that's usually how it breaks down in practice but even if the language directly provided format strings, I'd still call them format strings, and even if a library provided string interpolation, I'd call it string interpolation.
The difference is format strings are a string with indicators that say where to insert values, usually passed as additional arguments, which follow after the string. String interpolation has the arguments inside the string, which says how to pull the values out of the surrounding context.
Interpolation is where the value is placed directly in the string rather than appended as parameters.
Eg “I am $age years old”.
This does result in the side effect that interpolation is typically a language feature rather than a library feature. But there’s nothing from preventing someone writing an interpolation library, albeit you’d need a language with decent reflection or a one that’s dynamic from the outset.
Yep. Which is part of why I'd much rather talk accurately about it being the iterator that may or may not encounter newly added values.
That makes it a lot clearer where the problem is, which is also where the solution is: get the list of keys you want to work on ahead of time and iterate over those while modifying the map.
I also found this very confusing:
> When updating a map inside of a loop there’s no guarantee that the update will be made during that iteration. The only guarantee is that by the time the loop finishes, the map contains your updates.
That's totally wrong, right? It makes it sound magical. There's a light explainer but I think it would be a lot more clear to say that of course the update is made immediately, but the "range" iterator may not see it.