Nice work, but please don't change the function signature.

Order in unordered_set cannot be trusted because it depends upon implementation. In C++14, odd size vectors without repeated elements get unexpected results.

Learned from others:

• the zero value of []byte is zero-length slice, not nil (same for string)
• strings.Builder

P.S. (benchmark on "Hello, World!")

Running tool: /usr/local/go/bin/go test -benchmem -run=^$ -bench ^(BenchmarkBuilder|BenchmarkAppend)$

goos: linux
goarch: amd64
BenchmarkBuilder-8   	  564320	      1847 ns/op	      24 B/op	       2 allocs/op
BenchmarkAppend-8    	  552009	      1868 ns/op	      40 B/op	       3 allocs/op
PASS
ok  	_/tmp/tmp.5QdND3p4Gx	2.123s

What does unwords feel like ? :)

Yes, you are right!

I benchmarked this solution and your solution with valgrind, found:

total heap usage: 71 allocs, 71 frees, 9,658 bytes allocated
total heap usage: 20 allocs, 20 frees, 5,959 bytes allocated

• both built with cargo build --release
• run generate_shape(50)

• ,p+1 is redundant, [p..] is enough
• didn't realize there is zipWith :: (a -> b -> c) -> [a] -> [b] -> [c]

After debug, forgot to set y @ for y in 0..n to _.

f64.powi is better than f64.powf, because:

Using this function(powi) is generally faster than using powf.

Just Couldn't come up with using filter!

u8::max_value() == 255 && b'H' == 72 && b'8' == 104.

So, no overflow when cell.bytes().sum::<u8>() if given valid cell.