Golang matrix package
In your code you often use the expressions len(m) and len(m[0]). The code would become clearer if you defined proper names for these expressions, like:

func (m Matrix) Rows() int { return len(m) }
func (m Matrix) Cols() int { return len(m[0]) }


This way, you can write zeros := matrix.Zeros(m.Rows(), m.Cols()), which make the code operate in mathematical terms instead of those of the implementing programming language. These additional methods won't affect the performance of your program since the compiler will generate equally efficient code for these method calls. You can verify this by looking at the generated assembly code using go tool objdump. And if there should really be a difference, file a bug report at https://github.com/golang/go/issues.

To see whether you defined a good API for your matrix package, you should write a corresponding unit test:

package matrix_test

import "testing"

func TestZeros(t *testing.T) {
    m := matrix.Zeros(3, 3)
    ...
}


Note that I wrote package matrix_test instead of the usual package matrix. This little change (which is also little-known) makes this test file a black-box test, which can only access the exported things from the matrix package.

At this point I thought that there were no way to access an individual element of the matrix. Therefore you should add another method:

func (m Matrix) At(row, col int) float64 { return m[row][col] }


Maybe it is possible to access the matrix elements using the [] operator, but I would not recommend this since you might want to implement the matrix later in a different way. Maybe you will mainly handle sparse matrices, where most of the elements are zero. Then you would need to change the implementation type to be more memory-efficient, and that change should not affect any code that already uses your package.

Another benefit of the At method is that it clearly defines that the ordering of the coordinates is row, col. I don't know whether mathematicians are always consistent about this little detail, so it's better to explicitly document it somewhere. Programmers definitely aren't consistent in this regard, not even after 60 years of confusion. There's (x, y), (top, left), (left, top), (height, width), (row, col), (col, row), and so on.