5 ms·

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.

by aikah 10y ago

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?
- jerf 10y ago
  One of the worst places lack of generics hits is numeric code, because you really want to be able to write Vector<int> or Vector<byte> or Vector<complex> without having to write all that over and over, multiplied across a significant number of such structures you might want templated (matrices of several types, several types of math-vectors, several types of arrays, etc.), multiplied across a large number of operations on those types. Datastructures times types in them times operations on them comes out to a big number in numeric code. I've often thought that the utility of templates in numeric code is part of the reason people tend to overestimate its utility in other places. Seeing something really nail a solution in one domain and assuming it must be equally useful everywhere is a common programming community failure I've seen over the years, and I've been putting together a sort of list in my head of such things. (It currently includes "inheritance based OO is awesome because it nails writing GUIs", even though it's not so great for most other tasks, "FP is great because it nails writing compilers" which is getting more popular but it took more than just that, "data binding is great because it nails simple CRUD forms" but inevitably explodes in complexity beyond that, that sort of thing. Beware the techonology that is always demoed on the same use case every time, in every video and essay written about it.) (And I'm not saying templating is useless, any more than any of the other things I mentioned are useless. I'm just saying it's very easy to overestimate the importance and utility of the given technology if you only look at where it is at its absolute best. You really need to look at the whole picture.)
  - omginternets 10y ago
    So this is a very interesting way of describing language niches, because I've often felt that Go nails one thing very well: routing streams of bytes. Any time you have to deal with "plumbing" (for lack of a better term), Go makes the job absolutely trivial. In a sense, I think it's a shame that Go has made it's name as "a language for concurrency" because I think that the concurrency features are in fact supporting features of the aforementioned usage: streaming dumb bytes left and right. Otherwise stated, Go is concurrent because concurrency helps ship bytes; it's not concurrent for the sake of solving general concurrency problems. With that in mind, I'm still not clear on what makes Go's type system sub-par. I keep hearing this meme repeated, and although I know next to nothing about type theory, I have always found Go's type system to provide just enough scaffolding for byte-delivery pipework. Beyond that it just gets out of the way. Consider this: Go is formally a static language, but it behaves (in the sense of how it's used in a workflow) in a manner closer to a dynamic language (compile time is equivalent to ipython's warm-up time, go playground makes testing snippets interactively very simple, etc). I think it's an error to compare Go with C. Go feels more like Python with concurrency and type safety. So again: I understand the use-case for generics, but viewed through the lens of "nailing" the problem of shipping bytes (which again, I contend is Go's purpose), I fail to understand why Go's type system is repeatedly labeled as lacking. Go isn't Rust. It's not solving the same problems as Rust. From there, what is it that makes Go's type system shitty? I would describe it as "just enough type system". Other than generics, what is it that people are expecting this damn thing to do? I'm very much open to being wrong (especially since this would inevitably introduce me to some interesting languages), but I can't quite conceptualize what people have in mind when they complain about Go's type system.

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.

by 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?

jerf 10y ago
One of the worst places lack of generics hits is numeric code, because you really want to be able to write Vector<int> or Vector<byte> or Vector<complex> without having to write all that over and over, multiplied across a significant number of such structures you might want templated (matrices of several types, several types of math-vectors, several types of arrays, etc.), multiplied across a large number of operations on those types. Datastructures times types in them times operations on them comes out to a big number in numeric code. I've often thought that the utility of templates in numeric code is part of the reason people tend to overestimate its utility in other places. Seeing something really nail a solution in one domain and assuming it must be equally useful everywhere is a common programming community failure I've seen over the years, and I've been putting together a sort of list in my head of such things. (It currently includes "inheritance based OO is awesome because it nails writing GUIs", even though it's not so great for most other tasks, "FP is great because it nails writing compilers" which is getting more popular but it took more than just that, "data binding is great because it nails simple CRUD forms" but inevitably explodes in complexity beyond that, that sort of thing. Beware the techonology that is always demoed on the same use case every time, in every video and essay written about it.) (And I'm not saying templating is useless, any more than any of the other things I mentioned are useless. I'm just saying it's very easy to overestimate the importance and utility of the given technology if you only look at where it is at its absolute best. You really need to look at the whole picture.)
- omginternets 10y ago
  So this is a very interesting way of describing language niches, because I've often felt that Go nails one thing very well: routing streams of bytes. Any time you have to deal with "plumbing" (for lack of a better term), Go makes the job absolutely trivial. In a sense, I think it's a shame that Go has made it's name as "a language for concurrency" because I think that the concurrency features are in fact supporting features of the aforementioned usage: streaming dumb bytes left and right. Otherwise stated, Go is concurrent because concurrency helps ship bytes; it's not concurrent for the sake of solving general concurrency problems. With that in mind, I'm still not clear on what makes Go's type system sub-par. I keep hearing this meme repeated, and although I know next to nothing about type theory, I have always found Go's type system to provide just enough scaffolding for byte-delivery pipework. Beyond that it just gets out of the way. Consider this: Go is formally a static language, but it behaves (in the sense of how it's used in a workflow) in a manner closer to a dynamic language (compile time is equivalent to ipython's warm-up time, go playground makes testing snippets interactively very simple, etc). I think it's an error to compare Go with C. Go feels more like Python with concurrency and type safety. So again: I understand the use-case for generics, but viewed through the lens of "nailing" the problem of shipping bytes (which again, I contend is Go's purpose), I fail to understand why Go's type system is repeatedly labeled as lacking. Go isn't Rust. It's not solving the same problems as Rust. From there, what is it that makes Go's type system shitty? I would describe it as "just enough type system". Other than generics, what is it that people are expecting this damn thing to do? I'm very much open to being wrong (especially since this would inevitably introduce me to some interesting languages), but I can't quite conceptualize what people have in mind when they complain about Go's type system.