Go subtleties

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.

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.

Not quite.

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.

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.

"Am I out of date and we just call that string interpolation these days?"

It's all just spelling. Your compiler just turns

    x = "I want ${number/12|round} dozen eggs, ${name|namecase}"

into

    x = StrCon("I want ", round(number/12), " dozen eggs, ", namecase(name))

anyhow. It's not a huge transform.

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.

Mutating maps during iteration is a big red flag.

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.

> It's not a huge transform.

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.