Is the reason for the absence of a well-maintained dataframe library lack of demand? It looks like Gota and Dataframe-go are abandoned, while Gonum isn't particularly active. Did these wither on the vine because no one used them?

It's likely because it's a pain to call Fortran or C (I'd be suspicious of anyone trying to reimplement openblas in go).

Why would you be suspicious?

There is no good reason to pursue a project like this (or if there is, it would be very surprising to me), so it would reek suspiciously of "not invented here".

Because more likely than not, they're going to screw it up, and the choice to use go was not made for sound engineering reasons (go is not the only language this would apply to, but because of the lack of good FFI, its more likely to happen). The exception would be if said person had a solid background in numerical computing and was up-to-date with the state of the field, but that's pretty easy to find out.

I think it's lack of demand, yeah, but I think that's downstream of a real culture clash. Exploratory data analysis is just really not a good fit, culturally, for go. You don't want to be explicit about everything and check every single error case, etc.

But then it's natural to evolve production systems out of exploratory analyses, rather than re-writing everything from scratch, unless there is a very compelling reason to do that. The compelling reason is usually to get more speed, but that's not go's strong suit either.

Also anything that requires interop/FFI, syscalls, and lower level stuff. It's extremely hard to record your screen on Go, for example. On Rust this is much more doable and there even are crates for it

It's not impossible with Go, though. There's an amazing windows impl here: https://github.com/kirides/go-d3d

...but if you look at the code, it's clear that you have to work against the language in some capacity