Read CSV into 2D float array in Go
You might want to check that the input of stringValuesToFloats is valid (that every row has the same number of columns).


If you do that, you should document this behavior in ReadFromCsv.

Replace all for foo, _ := range … by for foo := range …. When you're not using the second argument, you don't need to discard it explicitly.


But instead of iterating on values, you could iterate on stringValues, and the inner loop could be for colIndex, s := range …, and you could use s instead of stringValues[rowIndex][colIndex].

var err error = nil → var err error.
When a function returns something, error and you want to return an error, you usually return the default value of something along with the error. So in stringValuesToFloats, you would return nil, err rather than values, err. This helps you make sure that you're not going to use the return value when you return an error.
Instead of printing the error with fmt.Println, you probably want to use log.Errorf and add an error message. Or not print anything at all and let the callers deal with the error (after all, it's why you return it), possibly returning fmt.Errorf("stringValuesToFloat: couldn't parse value %s", err) instead of just err.
Close the file after usage. Add defer file.Close().
Use a csv.Reader with option TrimLeadingSpace instead of trimming whitespace by hand. Your CSV file shouldn't have space after values (arguably, it shouldn't have spaces anywhere).
On "does this look like Go", I'd say you have too much whitespace (empty lines in functions are seldom used), line returns (you never see them right after declarations (:=) or assigments (=)), and your variable names are Java-level verbose. In Go, you would use i instead of rowIndex, floatArray instead of make2dFloatArray, ConvertCSV instead of ReadFromCSV, etc.


And, no, there's no easy way to have something more dynamic that float64, unless you have a specific use case in mind (and then, you would use an interface, but this is out of scope for this question). See this for a detailed discussion on why Go doesn't have generics for now.