13 ms·

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 ha

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.

theparanoid 10y ago
Lacking SSE2/4 is a big factor. The gonum packages use assembly in performance critical sections for this reason.
pjmlp 10y ago
> it won't be as fast as C++. People used to say the same of C++ against C and Pascal compilers. Where would C++ compilers be now, if C++ compiler vendors had given up?
- joelthelion 10y ago
  I don't think getting performance on par with C or C++ is even among the design goals of Go, but I could be wrong. Within one order of magnitude? Sure. But not on par.
  - pjmlp 10y ago
    Anyone is free to implement a compiler for Go. Who knows what the goals of this person might be.
- baldfat 10y ago
  The issue was when those statements were made computers were super slow. This was where FORTRAN became king of scientific computing.
  - pjmlp 10y ago
    Those were the 50 and 60's, C was yet to be invented and only became competitive against Fortran compilers after restrict was added (C99) and the special scientific extensions from the ANSI working group for numerical computing. Should C compiler vendors also given up against Fortran compilers?
pella 10y ago
>Not sure Go is such a great fit for scientific computing. "Go Data Science Tooling, Packages, Libraries, etc." https://github.com/gopherds/resources/tree/master/tooling https://github.com/gopherds/resources/tree/master/tooling
- aikah 10y ago
  Now compare with the tooling, packages, libraries in C++ or Python.
  - pjmlp 10y ago
    Now imagine someone proposing C++ or Python libraries on Usenet for scientific computing, around 20 years ago. I am not a big fan of how Go's type system turned out to be, but do see it positive that people take the effort of bringing alternatives into the eco-system.
    - deleted 10y ago
      [deleted]
aikah 10y ago
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 10y ago
  Python with Numpy/Scipy. The Python there is just calling high performance fortran libraries.
  - masklinn 10y ago
    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 10y ago
      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.
- messe 10y ago
  > Go's poor type system is a bigger issue. This. I think Julia[1] had the right idea about multiple dispatch. [1]: http://julialang.org http://julialang.org
- omginternets 10y ago
  What makes Go's type system poor?
blablabla123 10y ago
I didn't like the lack of templates when implementing some Linear Algebra stuff. You can definitely do it but I prefer using C++ or a dynamic language for that...
zem 10y ago
also there's julia, which is being designed from the ground up for this domain. if i were working on a scientific computing library that would be my first choice of ecosystem to target.

theparanoid 10y ago

Lacking SSE2/4 is a big factor. The gonum packages use assembly in performance critical sections for this reason.

pjmlp 10y ago

> it won't be as fast as C++. People used to say the same of C++ against C and Pascal compilers. Where would C++ compilers be now, if C++ compiler vendors had given up?

joelthelion 10y ago
I don't think getting performance on par with C or C++ is even among the design goals of Go, but I could be wrong. Within one order of magnitude? Sure. But not on par.
- pjmlp 10y ago
  Anyone is free to implement a compiler for Go. Who knows what the goals of this person might be.
baldfat 10y ago
The issue was when those statements were made computers were super slow. This was where FORTRAN became king of scientific computing.
- pjmlp 10y ago
  Those were the 50 and 60's, C was yet to be invented and only became competitive against Fortran compilers after restrict was added (C99) and the special scientific extensions from the ANSI working group for numerical computing. Should C compiler vendors also given up against Fortran compilers?

pella 10y ago

>Not sure Go is such a great fit for scientific computing. "Go Data Science Tooling, Packages, Libraries, etc." https://github.com/gopherds/resources/tree/master/tooling https://github.com/gopherds/resources/tree/master/tooling

aikah 10y ago
Now compare with the tooling, packages, libraries in C++ or Python.
- pjmlp 10y ago
  Now imagine someone proposing C++ or Python libraries on Usenet for scientific computing, around 20 years ago. I am not a big fan of how Go's type system turned out to be, but do see it positive that people take the effort of bringing alternatives into the eco-system.
  - deleted 10y ago
    [deleted]

aikah 10y ago

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 10y ago
Python with Numpy/Scipy. The Python there is just calling high performance fortran libraries.
- masklinn 10y ago
  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 10y ago
    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.
messe 10y ago
> Go's poor type system is a bigger issue. This. I think Julia[1] had the right idea about multiple dispatch. [1]: http://julialang.org http://julialang.org
omginternets 10y ago
What makes Go's type system poor?

blablabla123 10y ago

I didn't like the lack of templates when implementing some Linear Algebra stuff. You can definitely do it but I prefer using C++ or a dynamic language for that...

zem 10y ago

also there's julia, which is being designed from the ground up for this domain. if i were working on a scientific computing library that would be my first choice of ecosystem to target.