2 ms·

But 99% (probably 100%) of scientific computing users do need FFI, hence why there's no overlap. While there may be other compilers, my impression is most Go de

But 99% (probably 100%) of scientific computing users do need FFI, hence why there's no overlap. While there may be other compilers, my impression is most Go devs, and hence most Go libraries, assume you're using the standard golang compiler, and so FFI remains a problem for expanding the Go ecosystem to specific use-cases. I'm not suggesting Go has support scientific computing (in fact, it's likely better for everyone if it doesn't), but it's likely Go will continue to be a non-entity in scientific computing landscape, absent someone throwing loads of money at a specific use-case and effectively locking people in. It's worth noting that other new languages (e.g. Rust) are being adopted, because they have an reasonable FFI story.

randomdata 3y ago
99% of scientific computing tasks are script in nature, so Go is not a good fit anyway. It is decidedly a systems langue, not a scripting language. Different tools for different jobs. Yes, obviously you can write scripts in a systems language, and systems in a scripting language, but you will have a better time if you write systems in systems languages, and scripts in scripting languages. There is good reason why we make a distinction between the two. The scientists are almost certainly using Python. If not Python, R or Julia. And that is in large part because these are scripting languages. It is true that amongst the 1% that are systems, Rust has found a place, but it too will never make any serious headway into the scripting realm. It is also a systems language. Different tools for different jobs.