Gosl – Go scientific library
github.com
github.com
That said, it's always useful to have a good scientific library in every language.
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?
Who knows what the goals of this person might be.
Should C compiler vendors also given up against Fortran compilers?
"Go Data Science Tooling, Packages, Libraries, etc."
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.
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.
Bottom line, when you're using an established Python scientific computing library to do numerical calculations, you're calling C (or maybe Fortran) routines.
This. I think Julia[1] had the right idea about multiple dispatch.
[1]: http://julialang.org
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.)
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.
In that global context... Go's type system is about as simple as they come. It's actually hard to come up with a statically-typed language that, in practice, is simpler. The type system in C itself is technically simpler, but with preprocessor macros I'm not sure if it's simpler in practice. I'd say that's why it's generally labeled as "lacking"; on the scale of type system complexity, it's near the bottom before you get into dynamic languages.
If you'd like to learn why that might be a problem for people, I recommend jumping in the deep end and learning Haskell for what strong type systems can guarantee.
There are certainly times I find myself unable to say things in the type system that I would like to be able to say in Go's type system, even given that I am in fact writing network servers with it. I take the tradeoff because in the context I'm working, the simplicity of code tends to win out even so.
Also: https://news.ycombinator.com/item?id=10208075#10208636
And I would fully agree that a non-trivial amount of Go hatred (but not all) occurs from people picking it up and trying to use it in a context they should never have even picked it up for. (That said, I tend to consider scientific programming one of those, and a burgeoning community seems intent on proving me wrong, so shrug.)
If I'm being honest with myself, I too have serious reservations about the extent to which Go is suited for scientific computation.
> I recommend jumping in the deep end and learning Haskell for what strong type systems can guarantee.
I'm superficially familiar with Haskell's typeclass system, but respectfully, this misses my point. What use is such a system in the context of scientific computing, or in the context of Go's mission?
I understand that there are type systems with stronger guarantees, but again, Go is not Haskell. Go is not Rust. Go is not solving these problems. My question is, in practice, what features of a type system are "these people" (the ones complaining about Go's type system -- I don't presume to label you, jerf, as one of them) pining for?
My (respectful) exasperation stems from the fact that these arguments usually compile down to something roughly equivalent to "Rust exists so why is Go not Rust? (Or Haskell)".
>I take the tradeoff because in the context I'm working, the simplicity of code tends to win out even so.
But this is exactly my point. At some point, adding features to the type-system is going to reduce the simplicity you enjoy in the context of problems for which Go was engineered. I appreciate that (to quote your linked comment) "the further away from a 'network server' you get, the less appealing Go gets", and that every success story you encounter with Go involves network servers. Moreover, I agree. Go nails this particular problem space, and I contend that this is in part because of the fast-and-loose design of its type system. We are in agreement with respect to Go's problem domain, and we are in agreement with respect to the fact that Go should not be viewed as a general-purpose concurrency language. These points, however, do not address the question of its type system.
So again: what more do you want this type system to do in the context of writing network servers? Which specific features from Haskell do you find yourself wanting, and what guarantee do we have that this would not undermine the simplicity and dynamic-i-ness that has made Go successful as a plumbing language?
>That said, I tend to consider scientific programming one of those, and a burgeoning community seems intent on proving me wrong, so shrug.
I'm inclined to agree with the caveat that certain disciplines (molecular bio and genetics for instance) increasingly rely on high-throughput streams of data. Perhaps Go is well-suited to the pipework, and perhaps it's advantageous to perform simple data transforms natively prior to doing the heavy lifting in Python or Julia ... I nevertheless remain unconvinced.
I suggest becoming more than superficially familiar, then. With all due respect, I believe your core problem is that you do not understand what advanced type systems can do, so it's a mystery to you why anybody would want them, and the only cure for that is to go learn. Again, let me emphasize, I do not mean this to be mean, but sometimes there's just no way around the problem in an HN-post sized reply.
I know one recurring thing I've encountered is that I'd love to be able to say that in
type Something interface {
DoWhatever() Something
}
On the balance I still use it for my job because the benefits outweigh the costs, but there are tradeoffs I make for it.
It's a work in progress :)
>With all due respect
No offense taken
> I know one recurring thing I've encountered is that I'd love to be able to say that in [...] that the return result of DoWhatever is guaranteed to be the same type as the thing you called it on
Forgive me, but isn't this generics all over again, or am I missing something?
And once more, is it possible to bake these features into the type system without requiring more boilerplate code? I like the idea of strong guarantees of a type system, but I worry about having to wrestle with the compiler. One of the things I really like about Go is that the type system provides guidance but I don't spend much time making the compiler accept things that I patently know are compatible (I'm looking at you, Rust).
Oberon-07
https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.Repor...
That's not a meme. People using statically typed languages want compile time safety, not heavy reflection and ad hoc type creation at run time like in Go. I'm not interested in having to use void pointers everywhere just to get a bit of code reuse. Go type system is shitty, its authors know it, but they are too arrogant to acknowledge that fact publicly.
> Other than generics
The absence of generics is the issue.
In practice I rarely use `interface{}`. I really am open to being wrong about this, but it would be nice if someone could show me what might be improved. So far everyone is just telling me that it can be improved and that "Go's type system is shitty".
I want to be convinced. I really do. I'm just not.
Even JuliaStats followed a similar distribution (https://github.com/JuliaStats), and it looks neat and organized.
Why?
There are clear drawbacks, but there are clear advantages as well.
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?
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.
(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).
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.