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

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.

Didn't realize sort_by is a method of Module Enumerable.

str.chars is a shorthand for str.each_char.to_a (ref: http://ruby-doc.org/core-2.5.0/String.html#method-i-chars)

So, use str.chars before .map is inefficient.

learned a lot from this kata!