Can Golang multiply strings like Python can?

It has a function instead of an operator, strings.Repeat. Here’s a port of your Python example, which you can run here:

package main

import (
    "fmt"
    "strings"
    "unicode/utf8"
)

func main() {
    x := "my new text is this long"
    y := strings.Repeat("#", utf8.RuneCountInString(x))
    fmt.Println(x)
    fmt.Println(y)
}

Note that I’ve used utf8.RuneCountInString(x) instead of len(x); the former counts "runes" (Unicode code points), while the latter counts bytes. In the case of "my new text is this long", the difference doesn’t matter since all the runes are only one byte each, but it’s good to get into the habit of specifying what you mean:

len("ā") //=> 2
utf8.RuneCountInString("ā") //=> 1

Since this was a Python comparison question, note that in Python, the one function len counts different things depending on what you call it on. In Python 2, it counted bytes on plain strings and runes on Unicode strings (u'...'):

Python 2.7.18 (default, Aug 15 2020, 17:03:20)
>>> len('ā') #=> 2
>>> len(u'ā') #=> 1

Whereas in modern Python, plain strings are Unicode strings:

Python 3.9.6 (default, Jun 29 2021, 19:36:19) 
>>> len('ā') #=> 1

If you want to count bytes, you need to encode the string into a bytearray first:

>>> len('ā'.encode('UTF-8')) #=> 2

So Python has multiple types of string and one function to get their lengths; Go has only one kind of string, but you have to pick the length function that matches the semantics you want.

Oh, it’s also worth noting that the Golang concept of a "rune" doesn’t (and can’t) solve the problem that in Unicode, the question "How much string is one character?" does not always have a well-defined answer. Earlier I used the string "ā" as an example of a two-byte one-rune string. But this very similar-looking string – "ā" – is actually four bytes or two runes long. The first one is U+0101 LATIN SMALL LETTER A WITH MACRON, while the second is U+0061 LATIN SMALL LETTER A followed by U+0304 COMBINING MACRON. Proper Unicode processing will treat them as equal to each other (picking one of them as the normalized form depending on which Normalization Form is selected) but there’s not really any sense in which the Platonic ideal string they’re both equivalent to can be said to contain a definite number of code-points.