[jerf]

I'd suggest "now" is actually a terrible time to try to make Go do scientific computing. With generics all-but-guaranteed to be incoming, but also not here yet, a lot of what you would do is going to be superceded in the forseeable future, on the same sort of time scale as your library's expected completion date.

I'd say that even once Go has generics, that will simply take it from being an awful scientific programming language to a mediocre one. I don't really understand why there's a few people who seem to think it's a good idea to try to do their scientific computing in Go when there are so many better options for that that already exist.

Post-generics, though, if you really insist, it will probably be the case that Go can be upgraded from "mediocre" to "tolerable" with a lot of library work. (Part of the "mediocre" is lacking libraries. That aspect can be fixed.) But it'll be hard to start that work without running generic code. Even if you assume the current documentation is the final specs, you still won't be able to guess the performance implications of anything you'd be blindly writing, and performance is very important for this sort of code.

[stcredzero]

With generics all-but-guaranteed to be incoming, but also not here yet, a lot of what you would do is going to be superceded in the forseeable future

I didn't mean "now" as in right this second. Generics will indeed be key.