back in the days, one always had to have 2 terminals open to work with ROOT: one to work and the other to 'kill -9 root.exe' thanks to CINT happily completely destroying your TTY.
IMHO, ROOT[3-5] is too many things with a lot of poorly designed API and most importantly a lack of separation between ROOT-the-library and ROOT-the-program (lots of globals and assumptions that ROOT-the-program is how people should use it).
ROOT 6 started to correct some of these things, but it takes time (and IMHO, they are buying too much into llvm and clang, increasing even more the build times and worsening the hackability of ROOT as a project)
Also, for the longest time, the I/O format wasn't very well documented, with only 1 implementation.
Now, thanks to groot [1], uproot (that was developed building on the work from groot) and others (freehep, openscientist, ...), it's to read/write ROOT data w/o bringing the whole TWorld.
Interoperability. For data, I'd say it's very much paramount in my book to have some hope to be able to read back that unique data in 20, 30, ... years down the line.
> 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.
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:
I have been using Gonum for some time now (also contributed, mostly in the plotting area).
Last summer, I tried an experiment: have a student migrate a little python-based analysis to a Go-based one.
The analysis was fitting some cosmological constants out of the so called Hubble diagram.
I was pleased to see that, in the span of 2-3 months, the student who had limited knowledge in programming (a bit of python), managed to pull off the minimization of a 740 supernovae dataset with a 2220x2220 nuisance parameters matrix.
and the run time was 2x faster than the python one (with scipy/minuit for the minimization, so everything in C/C++, really).
success. :)
(and this motivated us to completely switch to Go as a teaching language for our master in particle physics / cosmology.)
I was challenging your "Go is not set up to have a REPL" assertion.
we are in violent agreement about the (non) "REPL-ness" of _gore_ and the fact that "just keep compiling a module incrementally" is a dead end.
I don't see how reimplementing Go in Go but with a REPL (on top of, let's say, a SSA interpreter) is a Go-like REPL at best and not just a Go REPL.
Could you expand a bit?
AFAICT, once one has a Go interpreter (the x/go/ssa is basically just that), implementing a REPL is "just" providing a program counter to the interactive interpreter layer, together with the ability to modify that PC... (many details have been dropped on the floor, of course)
It is a true REPL (not like "gore", mentioned somewhere in that thread).
It doesn't implement the whole Go specs, but there's AFAICT nothing in the Go specs that prevent `igo` to implement the whole Go specs.
It's "just" work.
Moreover, with the introduction of the "buildmode=plugin" in the yet-to-be-released Go-1.8, import-ing packages on the fly should be easy implementable.