
Gosl – Go scientific library - wener
https://github.com/cpmech/gosl
======
joelthelion
Not sure Go is such a great fit for scientific computing. On the one hand,
with garbage collection and other things, it won't be as fast as C++. On the
other hand, it's less flexible than Python.

That said, it's always useful to have a good scientific library in every
language.

~~~
aikah
I don't think the speed is the problem here. Plenty of sci stuff is done in
Python. Go's poor type system is a bigger issue.

~~~
yiyus
Python with Numpy/Scipy. The Python there is just calling high performance
fortran libraries.

~~~
masklinn
It's not quite that simple. The core packages wrap fortran or C code but then
additional packages are built on that. Going by the github breakdowns Pandas,
SymPy or Jupyter are pretty much pure Python, matplotlib is 90% Python 10% C++
(though the Python ratio is probably skewed up by the in-repo examples).

And that high-performance Fortran or C code is at the root of so much
scientific computing is an issue in Go considering the overhead of cgo calls.

~~~
nickdavidhaynes
Jupyter and matplotlib aren't designed to actually do any calculation (they
are just for communicating results) so it doesn't make sense for them to be
written in C. Pandas has a ton of pure Python code, but if you dig through the
layers of abstraction, all of the core algorithms are implemented in cython or
make calls to numpy (which is calling C code).

Bottom line, when you're using an established Python scientific computing
library to do numerical calculations, you're calling C (or maybe Fortran)
routines.

------
howeman
Wow! That's a ton of stuff. I wish you were working with us at gonum. Can we
work together?

~~~
saturn_vk
Is there a reason why every component of gonum is scattered across different
repositories. For me, it makes it extremely hard to browse through the stuff
and try to find anything that might be useful to me.

~~~
Dawny33
I find it quite legit. Having a singe repo would hinder progress as more and
more implementations are added.

Even JuliaStats followed a similar distribution
([https://github.com/JuliaStats](https://github.com/JuliaStats)), and it looks
neat and organized.

~~~
ngrilly
> Having a singe repo would hinder progress as more and more implementations
> are added.

Why?

~~~
Taek
You're more likely to touch more files if they are all in the same repository.
All of the issues are going to be in the same issue tracker (tags can help,
but only if you know how to use them well, and that causes overhead for the
maintainers), and all of the Pull Requests are going to notify everyone who is
watching the repository, whether it's relevant to the part you care about or
not.

There are clear drawbacks, but there are clear advantages as well.

------
gtani
Wow, that's a lot of good work.

I asked recently about go wrappers for the Cuda Runtime or Driver API's and
didn't get much response, I don't see a lot happening with openCL either, is
there anything like that in the prospects?

[https://news.ycombinator.com/item?id=12528206](https://news.ycombinator.com/item?id=12528206)

------
pm90
While this looks like great stuff and there is no way I will discourage anyone
from developing tools for scientific computing in any programming language,
the vast majority of users of these tools IMO are scientists and engineers who
are not programmers. Or to put it another way, most of them don't have a
degree in CS, they are usually Mathematicians, Physicists etc. When I hung out
in that community about 3 years ago, there was already a wholesale movement
going on in moving from MATLAB and/or Fortran to Python... and I don't think
the vast majority of that community (which is generally conservative when it
comes to tooling) will adopt yet another tool unless it offers some
significant benefit. (MATLAB was easy to write and use but proprietary. Python
was easier and free. Both make use of high performance libraries written in
C/Fortran).

~~~
gautamdivgi
Yup. I'm one of those people. Well, partially at least. I do a lot of
distributed computing. But my PhD was in a statistical area.

I used Octave for a while (matlab clone). But then as my data sets got larger
and I mean really large (non-linear equation solving on 11m points on my puny
desktop), I went full force on Python (NumPy, SciPy, Matplotlib). The reason -
its is super easily scriptable, the libraries are great and easy to use and
python allows me to use multi-processor capabilities to distribute my work to
all my cpu cores.

Keep in mind I could have used GSL. But Numpy/Scipy & matplotlib were just
faster and more productive for me.

That being said, I'd rather have one source of truth - i.e. GSL and have this
be a wrapper around it as opposed to re-creating all the logic.

Either way - its a fantastic effort. If at anytime I create systems that need
numerical computation (as opposed to the hacks that I did for my thesis) I
will definitely look into this.

------
IndianAstronaut
The excitement and libraries around Go remind me of Python around 2009.

~~~
coldtea
So, like that totally irrelevant time for Python when nothing special was
going on?

(Edit: not that Python was itself irrelevant, but 2009 was an irrelevant time
for Python, when nothing special news/projects/etc wise for Python. I've been
using the language since 1998, and the most "hyped" period was in the early
00s. Mid 00's Ruby/Rails caught on).

~~~
IndianAstronaut
This was around when Numpy and Scipy were taking off. Pandas, scikit learn,
theano, started development soon after.

~~~
coldtea
That was more of a slow adoption and consolidation that some dramatic spike.

Numpy (renamed as such around 2006) has been around for like 20 years, and has
been quite popular in the noughties too for those doing numeric stuff in
Python.

