▲ | Mawr 7 days ago | |
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:
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:
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... | ||
▲ | pansa2 7 days 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? |