[sbinet]

others have already mentioned Gonum:

- https://gonum.org

Gonum is almost on par with _e.g._ NumPy/SciPy (most notably lacking: ODEs). So still ways to Go but it's getting there.

Go-HEP is my attempt to bring a few High Energy Physics oriented packages to particle physicists:

- https://go-hep.org

I've also written a few words on why I think Go is great for science:

- https://sbinet.github.io/posts/2018-07-31-go-hep-manifesto/

TL;DR: Go is great b/c it brings great s/w engineering practices and a s/w engineering-friendly environment to scientists.

Admittedly, generics will change how packages are written. So some code churn will take place when/if they land, but the Go community learned the lessons from Python2/3 and Perl5/6. Expect a better migration path.

Lastly, I guess the 2 remaining weak points of Go are:

- runtime performances sub-par wrt C++ or Rust

- GUIs (which may or may not fall into "interactive visualization")

That said, the Go community worked on a Go kernel for Jupyter:

- https://github.com/gopherdata/gophernotes

- http://gopherdata.io/

hth, -s

[tptacek]

Gonum is neat, but to the previously-made point about Go's type system making stuff more painful than it needs to be in this application: gonum's linear algebra is defined over float64 and int, which is problematic if you need arbitrary precision.

[sbinet]

I guess it's scientific domain dependent. I've very rarely needed something else than float/double in my C++ days or REAL*8 in my F77 ones.

sure, when you need it, you need it. but float64 caters for a good 99% of my usual work day.

From a user POV, seamless installation of packages is a great boon. From a grid/cloud operator POV, static binaries are great too.

[tptacek]

These are things that are great for product development and devops and not in fact all that valuable in scientific computing, which is a reason why so much of it gets done in Python.

[sbinet]

> These are things that are great for product development and devops and not in fact all that valuable in scientific computing

I disagree. Again, this may very well be science-domain dependent, but in High Energy Physics (where, finally, Python is recognized as a mainstream language, BTW) many -- if not all -- of the pain points that slow down undergrads, PhDs, post-docs and researchers at large, are these Go features.

yes, the time from "idea" to "little script that shows a bunch of plots" on a subset of the overall data is definitely shorter in Python (exploratory analysis is really really great in Python). but, at least for LHC analyses, python doesn't cut it when it comes to Tb of data to swift through, distribution over the grid/cloud, ... you die by a thousand cuts. and that's when you are alone on one little script. LHC analyses can see well over 10-20 people assembling a bunch of modules and scripts. You really long for a more robust to (automated) refactoring language than python, pretty quickly.

[mbo]

What's wrong with Julia, a language purpose built for scientific computing?

[chewxy]

There's Gorgonia too! :)