> Go developers seem to have taken no more than 5 minutes considering the problem, then thoughtlessly discarded it: [2]. A position born from pure ignorance as far as I'm concerned

There are a million things in go that could be described this way.

▲ unscaled 3 months ago | parent [-]

Looking at the various conversations involving string interpolation, this characterization is extremely unkind. They've clearly spent a lot more than 5 minutes thinking about this, including writing their own mini-proposals[1].

Are they wrong about this issue? I think they are. There is a big difference in ergonomics between String interpolation and something like fmt.Sprintf, and the performance cost of fmt.Sprintf is non-trivial as well. But I can't say they didn't put any thought into this.

As we've seen multiple times with Go generics and error handling before, their slow progress on correcting serious usability issues with the language stem from the same basic reasons we see with recent Java features: they are just being quite perfectionist about it. And unlike Java, the Go team would not even release an experimental feature unless they feel quite good about it.

[1] https://github.com/golang/go/issues/57616

▲ mananaysiempre 3 months ago | parent | next [-]

> There is a big difference in ergonomics between String interpolation and something like fmt.Sprintf

On the other hand, there’s a difference in localizability as well: the latter is localizable, the former isn’t. (It also worries me that I see no substantive discussion of localization in PEP 750.)

▲

lou1306 3 months ago | parent [-]

T-strings should also help localizability, you can now just retrieve them from a locale -> t-string mapping and they should Just Work. Or am I missing something?

	▲	mananaysiempre 3 months ago \| parent [-]
		There are two sides to this: First—and more importantly—a professional translator’s interface is list of strings and some supplementary materials in, list of strings out. (Protip: given baseline i18n competence like not concatenating sencences out of parts, the quality of the translation you get is largely determined by the supplementary materials; screenshot every part of your UI and your translator will be willing to kiss you.) Both in communicating with clients and on the fast path of their own work (in CAT software like Across, Trados, etc.). They do not need to see the code that fills in any placeholders, nor do they want to spend time and attention preserving it exactly as it’s been written—they just want to reorder the placeholders as the syntax of the language dictates. Arguably even %s vs %d is too much information. The ideal is {name} and {count}, and {1} and {2} are acceptable. (By contrast, a very common issue is that like half of the sentence may need to change depending on the numeric value filled in for {count}, and two variants in English may map to anywhere between one and four after localization[1]. Template strings help with this not at all.) Second—though this may be easier to fix—the two major ways to retrieve localized messages at runtime are integers in, strings out (most commercial tools out there) and strings in, strings out (GNU gettext), where the output strings are retrieved from some sort of data file that’s intentionally incapable of containing executable code (resource-only “MUI” DLLs, hashtables in GNU “MO”s, plain old text in Java “properties”, various kinds of XML, etc.). Operating on pure data isn’t a strict necessity. It’s is largely a concession to the development process, which may not permit the string tables to go out to the localization contractors until principal QA is finished. The last thing you want is to insert engineering into the already-slow loop between the translators, the editors (or a translation agency employing both), and localization QA (hopefully in-house, using the actual live software to check the translations in context). [1] https://www.gnu.org/software/gettext/manual/html_node/Plural...

▲ Mawr 3 months ago | parent | prev [-]

I just expect better from professional language designers. To me, the blindingly obvious follow up to the thought "We understand that people familiar with other languages would like to see string interpolation in Go." [1] is to research how said other languages have gone about implementing this and to present a brief summary of their findings. This is table stakes stuff.

Then there's "You can [get] a similar effect using fmt.Sprint, with custom functions for non-default formatting." [2]:

- Just the fact that "you can already do this" needs to be said should give the designers pause. Clearly you can't already do this if people are requesting a new feature. Indeed, this situation exactly mimics the story of Go's generics - after all, they do not let you do anything you couldn't do before, and yet they got added to Go. It's as if ergonomics matter, huh.

Another way to look at this: if fmt.Sprint is so good it should be used way more than fmt.Sprintf right? Should be easy to prove :)

- The argument crumbles under the load-bearing "similar effect". I already scratched the surface of why this is wrong in a sibling post: [3].

I suspect the reason for this shallow dismissal is the designers didn't go as far as to A/B test their proposal themselves, so their arguments are based on their gut feel instead of experience. That's the only way I can see someone would come up with the idea that fmt.Sprint and f-strings are similar enough. They actually are if all you do is imagine yourself writing the simplest case possible:

    fmt.Sprint("This house is ", measurements(2.5), " tall")

    f"This house is {measurements(2.5)} tall"

Similar enough, so long as you're willing to handwave away the need to match quotation marks and insert commas and don't spend time coding using both approaches. If you did, you'd find that writing brand new string formatting statements is much rarer than modifying existing ones. And that's where the meat of the differences is buried. Modifying f-strings is trivial, but making any changes to existing fmt.Sprint calls is painful.

P.S. Proposing syntax as noisy as:

    fmt.Println("This house is \(measurements(2.5)) tall")

is just another sign the designers don't get it. The entire point is to reduce the amount of typing and visual noise.

[1]: https://github.com/golang/go/issues/57616#issuecomment-14509...

[2]: https://github.com/golang/go/issues/34174#issuecomment-14509...

[3]: https://news.ycombinator.com/item?id=43651419

	▲	pansa2 3 months ago \| parent [-]
		> Proposing syntax as noisy as […] is just another sign the designers don't get it. Are you objecting to the use of `\(…)` here instead of `{…}`? Because of the extra character or because of the need to nest parentheses?