by angrymouse on 3/27/21, 2:02 PM with 170 comments
by yashap on 3/27/21, 8:24 PM
Go is at the complete opposite end of the spectrum - not flexible at all, it’s purposefully difficult and awkward to write high level abstractions/DSLs, there’s very poor functional programming support, and it’s very verbose. There are great reasons for these restrictions, they’re intentional design decisions, but they also make it a very poor fit for data science IMO.
by joppy on 3/27/21, 3:09 PM
by carbocation on 3/27/21, 3:06 PM
This is Hacker News, so there definitely doesn't need to be anything beyond "I could, so I did." But if this actually solves some problem better than existing solutions, it would be cool to read about. Edit: Without a motivating example, it's hard to imagine that people will want to pickup a Go-like (but not exactly Go) language for data science.
by MrPowers on 3/27/21, 3:42 PM
A basic DataFrame library would go a long way. Doesn't have to be as full featured as Pandas. Just something that's maintainable and portable.
I wrote a blog post a few months ago on the current Go DataFrame libraries (gota, qframe, dataframe-go): https://mungingdata.com/go/dataframes-gota-qframe/. None of the current offerings are integrated with Arrow.
An Arrow-backed Go DataFrame library that can read / write Parquet files could really jumpstart data science in Go (really data engineering in Go, which is where they should probably focus first).
by kzrdude on 3/27/21, 4:04 PM
</irrelevant unix nerd mumbling>
by iagovar on 3/27/21, 3:58 PM
by micro_cam on 3/27/21, 3:19 PM
However it is hard to get around the lack of operator overloading and (to a lesser extent at least to me) generics. I love the simplicity of the language and understand their feeling that operator overriding is too often abused but at the same time not being able to use algebraic operators for matrix and tensor libraries makes them really hard to use.
The compacting garbage collector can also make it hard to pass pointers to memory to non go libraries which is key in data science.
If this project could address those things I think it could have real potential
by dunefox on 3/27/21, 9:14 PM
by great_reversal on 3/27/21, 5:03 PM
by umvi on 3/27/21, 6:38 PM
It wants me to do if/else guards a certain way, you have to capitalize first letters of "exported" functions, it won't let me import `fmt` unless I use it, etc. I'm not sure I like it.
by amelius on 3/27/21, 10:48 PM
by unreliableNar8r on 3/27/21, 11:28 PM
In terms of being a general-purpose DS language, I can't imagine using anything that doesn't have a clear strategy to A) get a dataset into a DataFrame or similar, B) get my collaborators a plot in a way that is quick and easy, and C) a lesser extent, some kind of notebook/reporting tool.
They do say there is a lot of development going on but it seems like a space with a lot of great incumbents and a rapidly maturing up-and-comer in Julia.
edit: typo
by tpmx on 3/27/21, 4:27 PM
by daemonk on 3/27/21, 3:14 PM
by chartpath on 3/27/21, 3:40 PM
BUT, they have list comprehensions!! One of the main things I miss coming from Python.
by quixoticelixer- on 3/28/21, 4:23 AM
by Ambix on 3/27/21, 9:57 PM
by InvOfSmallC on 3/28/21, 6:46 AM
by JediPig on 3/27/21, 3:23 PM
by donutloop on 3/27/21, 10:13 PM
by dm319 on 3/27/21, 8:24 PM