[HN Gopher] Go+: Go designed for data science
___________________________________________________________________
Go+: Go designed for data science
Author : angrymouse
Score : 155 points
Date : 2021-03-27 14:02 UTC (8 hours ago)
(HTM) web link (goplus.org)
(TXT) w3m dump (goplus.org)
| dm319 wrote:
| When I realised I couldn't divide a time period by a number or
| integer, the penny dropped that different languages excel at
| different things.
| icholy wrote:
| Are you talking about `time.Duration`? Because you can
| definitely do that.
| robbyt wrote:
| But don't try to use BC dates with time.Duration, because
| they don't work!
| donutloop wrote:
| Many of these features should be part of the upcoming GO 2
| [deleted]
| carbocation wrote:
| I write a lot of Go, and I spend most of my time doing analysis
| (usually in R, occasionally in python). I'm interested to
| understand whether there was a specific motivating example that
| drove the creation of this new go-like language.
|
| 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.
| resonantjacket5 wrote:
| It seems it compiles down to golang usually? As in the read me
| they run ``` gop go tutorial/ # Convert all Go+ packages in
| tutorial/ into Go packages go install ./... ```
|
| It's more like typescript for javascript than a completely
| separate language.
| CameronNemo wrote:
| If you are looking to learn a language specific to data
| science, Julia is fairly mature.
| iujjkfjdkkdkf wrote:
| > 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
|
| Exactly. I use almost exclusively python (including for data
| science- or ML really). I've been wanting an excuse to learn Go
| by doing a project with it. But learning some third Go-like
| language would be a tougher sell for me, unless there is really
| something it does better than python, because it still doesnt
| give me the benefit of learning Go.
|
| But like someone else said, "because you can" is usually a good
| enough reason to build or learn a new language, so I'm sure
| it's still worth it for many.
| chartpath wrote:
| Agree with all the comments like "where are the nd arrays?"
|
| BUT, they have list comprehensions!! One of the main things I
| miss coming from Python.
| conradludgate wrote:
| Once generics get introduced into the language, you can write a
| generic map function which can take a []T and a func(T) U to
| return a []U. While it's not as elegant as a list
| comprehension, it's nicer than writing a for loop every time.
| Although, I can't remember what the performance impact of
| closures are in go, so this might not be a cheap operation.
| jhgb wrote:
| Why not something like a channel map? Give it a channel and a
| function and you get another channel with a goroutine running
| in the background.
| MrPowers wrote:
| Go has a ton of potential in the data science space.
|
| 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).
| bewuethr wrote:
| In the same GitHub organization, there is
| https://github.com/goplus/pandas, but it seems to not have
| progressed past a README.
| fractionalhare wrote:
| I can see a lot of potential in Go for data engineering
| specifically, yeah. Those would probably be some very stable
| and performant ETLs. And the concurrency and network primitives
| would make it easy to develop libraries like Prefect/Airflow.
| RSHEPP wrote:
| We use Go for our ETL, with some Python too. We are in the
| process of transitioning to Argo Workflows from a K8s
| CronJob/Job setup which has been pretty stable itself.
| MrPowers wrote:
| Yep, agreed. Go is a great language for AWS Lambda type
| workflows.
|
| Python isn't as great (Python Lambda Layers built on Macs
| don't always work). AWS Data Wrangler
| (https://github.com/awslabs/aws-data-wrangler) provides pre-
| built layers, which is a work around, but something that's as
| portable as Go would be the best solution.
| fractionalhare wrote:
| Love awswrangler. I use that over boto whenever I have the
| opportunity.
| andrewprock wrote:
| Data science is an experimental activity, whereas golang is
| explicitly a production platform. The amount of friction this
| will introduce is too high for practical use.
|
| For example, in golang you will get a complication error if you
| have an unused variable, leading to significant extra work when
| exploring code level alternatives.
| nerdponx wrote:
| Maybe a high-concurrency experiment runner or data flow engine,
| but Go would probably be the last "modern" language I think of
| as being good for data science.
|
| All of the features that make it great for writing high-
| concurrency web applications would make it painful for writing
| tabular data processing, array manipulation & linear algebra,
| and plotting.
|
| Nim seems a lot more practical; it's easy to bind to existing
| data science libraries, and you can use the macro system to
| build more expressive DSLs. That said, since Julia already does
| pretty much anything I would need to do (and will hopefully one
| day have a fast start up times and/or AOT compilation), I'm not
| sure why you would want to use Nim either. Maybe use it to
| write some kind of "mid-level" library code that binds to
| something like Torch, which you could then use from an even
| higher-level interactive language.
|
| Apart from the incumbents -- Julia, Python (grandfathered in +
| you can use Hy/Hissp/Coconut), and R -- maybe you could have a
| good time doing data science in Common Lisp or Racket. Again:
| good CFFI story, macros for expressive DSLs, flexibility to run
| in interpreted and compiled modes, dynamic/gradual typing for
| easy iteration, etc.
|
| Hell, I would sooner take Lua for data science over Go.
|
| That said, I am an "Arrow maximalist", because the beauty of it
| is that you should be able to use data frames even in Go if you
| really want to, without reinventing the CSV parsing and memory
| layout wheels.
| d110af5ccf wrote:
| > data science in Common Lisp or Racket
|
| Similarly, Chibi or Gambit Scheme.
|
| > I would sooner take Lua for data science
|
| Which provides for a low level language like Terra or a Lisp
| via Fennel or Urn.
| monkeyfacebag wrote:
| > Go has a ton of potential in the data science space.
|
| Does it? I'm not familiar with Go data science applications but
| the design of the language, tooling and runtime, eg low latency
| garbage collector, errors thrown for unused imports, do not, to
| me, seem to fit well with the needs of data science. I'm
| interested in hearing what advantages Go brings.
| jrockway wrote:
| How do unused imports relate to a language's suitability for
| data science? Your Python IDE adds and removes imports as you
| use them. Your Go IDE adds and removes imports as you use
| them. Unless you're using "ed" as your editor, it shouldn't
| even be something you see or ever think about.
| moooo99 wrote:
| I guess the best thing would be the lightweight and simple
| concurrency model of go when it comes to data science
| applications. But other than that, I can't really think of a
| good reason why go should have so much potential.
| mountainriver wrote:
| The biggest hurdle for Go in this realm is honestly the Go-->C
| FFI latency. It severely limits acceleration
| umvi wrote:
| I just barely picked up Go, and my first impression is that it's
| very... opinionated.
|
| 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.
| philosopher1234 wrote:
| The opinions are by design. By removing flexibility, you can
| increase uniformity. Instead of having 12 different styles of
| code, there can be 1. It removes cognitive load, so you can
| spend your mental energy on solving problems.
| umvi wrote:
| And that's fine if go were the only language I ever used, but
| it's jarring going from unopinionated languages to a highly
| opinionated one. I have to have a special set of "go rules"
| in my mind to be sure to follow when using go which has the
| effect of _increasing_ cognitive load. "oh right, go wants
| me to compress my if else clauses and put the brackets a
| certain way"
| philosopher1234 wrote:
| I don't that appreciates the value enough. Yes, there is a
| cognitive load to learning the opinions of go (though gofmt
| keeps you from having to learn a lot of them, as do
| compiler errors) but that is true of any language. I also
| think the number of opinions you need to learn is far
| smaller, as you don't have as big of a surface area to
| navigate when making design decisions about daily coding. I
| think they are net very positive.
| joppy wrote:
| The first things I would look for in a data science language are
| multidimensional arrays, linear algebra packages, data frame and
| time series libraries ... none of which feature on this page.
| fractionalhare wrote:
| Yeah I'm confused. The only "data science" I can see here is
| the the title.
|
| How is list comprehension a data science primitive? How did
| this get over 4,000 stars on GitHub with a glaring lack of
| basic data science functionality? Is this used by actual
| practitioners?
| wener wrote:
| Chinese based github project, the stars mostly are hyped.
| fixIt83 wrote:
| GitHub stars are bookmarks for me, not an indicator of
| usefulness.
|
| It does say it's under heavy development.
|
| Maybe 4.3k+ GitHub users just want to make sure they get
| updates?
| diarrhea wrote:
| Right next to Star is Watch, which would be much more
| suitable towards that, no?
| SamWhited wrote:
| No, Watch emails you a bunch. Stars just show up in a
| list so you can find it later. That being said, public
| bookmarks always seemed weird to me. Why not just
| actually bookmark it with your browser? Not that it
| matters.
| searchableguy wrote:
| If you are using github app, it's less friction to star
| it than open the page in the browser window and bookmark
| it.
| AlexCoventry wrote:
| What's the benefit of using the app?
| dgellow wrote:
| GitHub added a "custom events" for Watch. You can for
| example only watch on new releases. You should maybe
| check it out!
| SamWhited wrote:
| That's still not the same as stars, it still emails you.
| whimsicalism wrote:
| If you've ever tried to use Watch as a bookmark, I feel
| like it's obvious why that is not a good solution
| dgellow wrote:
| You may want to revise your judgement, GitHub added
| support to watch on "custom events", such as: new issues,
| new PRs, new releases, etc. You might want to try again.
| rustc wrote:
| I wish HN had a way to save a story without upvoting it or
| showing it publicly on your profile (the "favorite" feature
| implemented right now), like Reddit's "Save". Many times
| I'm interested in something to check out later but it's not
| something worth upvoting (like this story, based on other
| comments) and I want my interests to stay private.
| kkoncevicius wrote:
| This issue is better solved externally - using a bookmark
| manager. It would allow you to have all your "read later"
| links in one place rather than being scattered over
| different websites. Personally I use Safari's reading
| list feature for that.
| Abishek_Muthian wrote:
| Apart from Gonum[1] numerical libraries, I haven't found
| specific data science related Go libraries in my search for it
| for some hobby projects when compared to Python ecosystem.
|
| Interestingly Prose[2] A Go library for text processing yielded
| better results for named-entity extraction when compared to
| NLTK in my tests in terms of accuracy and obviously
| performance.
|
| Perhaps Go is not being applied enough in the Data Science/ML
| and for fields where it's applied (Network) Math in the
| standard library seems to be sufficient.
|
| [1] https://github.com/gonum/gonum
|
| [2] https://github.com/jdkato/prose
| xyst wrote:
| I might contribute a feature towards this, specifically a time
| series lib.
| kvnhn wrote:
| Thank you! I've seen this language/extension/library pop up a
| few times and I don't see, even remotely, how it could displace
| the Python data science stack. The biggest competitor to Python
| in this space, IMO, is Julia. Go+ seems light-years behind, and
| heading in the wrong direction entirely.
| edumucelli wrote:
| R is the competitor, actually many of things in the Python
| data stack are directly copied from R: seaborn's ~ operator,
| dataframe, ...
| aldanor wrote:
| Yea, my list would also be:
|
| - ndim arrays with broadcasting
|
| - time series
|
| - plotting
|
| - linalg: blas/mkl
|
| - storage - hdf5, zarr, arrow, parquet, netcdf
|
| I don't see any of those either in go+.
| indeedmug wrote:
| Seems like Julia could do all of those things.
| daemonk wrote:
| There are a lot of numerical structures missing from this. Not
| sure if you can really advertise it as for data science without
| some kind of dataframe structure.
| fractionalhare wrote:
| DataFrames? It doesn't even seem to have specialized array
| primitives like Series or NumPy. What the heck?
| dunefox wrote:
| There are quite a few languages I would like to use before Go.
| Especially F# seems very interesting for DS.
| bachmeier wrote:
| Even been wanting for some time to check out the F# R Type
| Provider: http://bluemountaincapital.github.io/FSharpRProvider/
| Unfortunately it appears to be Windows-only, and my curiosity
| hasn't yet reached the point that I'd boot into Windows.
| dunefox wrote:
| Sadly, it also doesn't work with .net core yet. Otherwise
| this would be a pretty convincing point for F#.
| great_reversal wrote:
| Why can't you just build libraries to make Go a better language
| for data science? There's already Go support for a Jupyter
| Notebooks kernel: https://github.com/gopherdata/gophernotes
| micro_cam wrote:
| I used to do a lot of machine learning code in go and think it
| has great potential as a compiled, static language with similar
| ease of development to python.
|
| 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
| elcritch wrote:
| Interesting, I wouldn't have thought of Go for ML. But I do
| share the enjoyment of static languages for Ml/data science.
| You might give Nim a look as it's pretty practical for wrapping
| C++ code!
| matsemann wrote:
| Ref operator overloading. As someone not used to python but had
| to read a simple numpy script last week, I was stumped for a
| while on this line of code: X[y==1,0] Just that.I first
| thought, what would X[False,0] be? Since y was a vector, it
| obviously wouldn't be equal to one. Okey, but extracting that
| part, it looks like y==1 takes my vector, and replaces with an
| array of same size, with true or false for each element.
| Basically == is overridden to run a predicate over all
| elements. Okey, but then what does X[[True,False,False..],0]
| mean? Looks like numpy has overridden the [] so one can pass an
| array of booleans in addition to a normal index, and then it
| only keeps those elements corresponding to True indexes.
|
| Clever and useful when done daily I guess, but damn it was hard
| to understand those 9 characters as someone not well-versed in
| this domain.
| iujjkfjdkkdkf wrote:
| I find this is common in python: there are nice shorthand
| things you can do that are definitely powerful, but they are
| not easy to understand nor to remember. Particularly with
| conditions applied to arrays / series this is a problem.
| "Truth of a series is ambiguous" is one of my most frequent
| errors.
|
| That said, the overall ecosystem still makes python the most
| practical general data science language in my view.
| DougBTX wrote:
| That example is using "logical vectors", which you'd come
| across in more data-science languages like Matlab, Octave, R,
| etc. Julia[1] has a more modern take on y==1, by having
| explicit syntax for element-wise operations, so it uses y.==1
| instead.
|
| What I'm really saying is that there's quite a bit of
| precedent for that syntax, but it comes from a more
| specialised field so it is easy to have not come across it
| before.
|
| [1] https://docs.julialang.org/en/v1/manual/functions/#man-
| vecto...
| nonameiguess wrote:
| MATLAB introduced automatic broadcasting of operators over
| n-dimensional arrays and logical indexing nearly 40 years and
| it is still the primary learning language for applied
| mathematicians, engineers, and scientists, and also a popular
| prototyping language for numerical algorithm developers. And
| it provides a great interactive REPL with built-in plotting
| for exploratory data analysis.
|
| Since doing this, the idea and basic syntax has been adopted
| by GNU Octave, S, R, and now NumPy and Matplotlib, which did
| it to make it easier for statisticians, engineers, and
| scientists to adopt Python. Specifically targeting these
| groups with familiar syntax is exactly why Python is so
| popular for data science, because data scientists tend to
| recruited from the hard engineering and science disciplines.
| It's a lot easier to teach basic programming to someone with
| a great background in applied math, experimental design, and
| research methods, than it is to teach all those things to
| programmers.
|
| This is an area in which languages with operator overloading
| shine, creating DSLs that mimic the syntax and semantics of
| other languages. _You_ might have a lot to learn because you
| 're used to == only being defined for scalar data types and
| arrays only being indexed by natural numbers, but the people
| the language is designed for are used to broadcasted
| operators and logical array indexing.
| marcus_holmes wrote:
| I never understand why operator overloading is said to make
| things more readable.
|
| If the meaning of an operator can change wildly with the
| operands then that's just confusing - you can't assume that
| '==' means what you think it means and you have to go find
| out what it means.
|
| In comparison, having an actual function name to clue me in
| on what something does is useful. Like, how is "X[y==1,0]"
| more readable in this case than something like
| "filterElements(arrayToFilter, arrayOfBools)"? (if I've
| understood what the original was trying to do, which I'm not
| sure I have).
|
| People seem to confuse "less typing" with "simpler", and
| that's not true. One of the great strengths of Go is that it
| rejects this and embraces true simplicity.
| yiyus wrote:
| > how is "X[y==1,0]" more readable in this case than
| something like "filterElements(arrayToFilter,
| arrayOfBools)"?
|
| Just the same way that a[i] *= b[j] is more readable than a
| .IndexElement(firstIndex).MultiplyByFloat(b.IndexElement(se
| condIndex))
| marcus_holmes wrote:
| yeah, sorry, but I didn't understand the first one at
| all, and totally understood the second one. Your
| definition of "readable" and mine differ ;)
| renox wrote:
| Bah, it's the same as Maths: notations 'compress' the
| formulas but at the cost of having to learn these
| notations..
| marcus_holmes wrote:
| yes, this. Completely.
|
| Is that more readable or less?
| renox wrote:
| For who? Beginners or experts?
| dragonwriter wrote:
| > I never understand why operator overloading is said to
| make things more readable.
|
| Because, used properly, it does.
|
| > If the meaning of an operator can change wildly with the
| operands then that's just confusing
|
| Yes, irresponsible use of operator overloading makes things
| confusing.
|
| Overloading enables preserving existing semantics with new
| types that have similar semantic roles, it also enables
| natural, concise, domain specific notation which may
| sometimes have different semantics than the standard use
| (while wild, unpredictable semantic swings hurt
| readability, humans are naturally quite good at
| incorporating context into interpretation of
| symbols/language, and avoiding context sensitivity for
| naive simplicity does not aid readability.)
|
| Verbosity can be quite bad for the ability to quickly grasp
| the meaning of things.
|
| > People seem to confuse "less typing" with "simpler
|
| Conciseness (not mere terseness, but clarity and terseness
| together) greatly aid readability. Verbosity is not zero-
| cost.
| marcus_holmes wrote:
| > Conciseness (not mere terseness, but clarity and
| terseness together) greatly aid readability. Verbosity is
| not zero-cost.
|
| I've been coding for 40-ish years. I've never found this
| to be true. Simple expressions are (in my experience)
| more readable.
|
| I understand it like this: to understand a complex
| expression you have to unpack it in your head to a
| simpler version in order to grok it. This is an operation
| you don't need to do if the expression is in the simpler,
| more verbose, version in the first place.
|
| This is a known thing in writing, btw - complex sentences
| are harder to read. If you want your audience to
| understand you, write more, simpler, sentences.
| dragonwriter wrote:
| > I've been coding for 40-ish years.
|
| Good for you, I've only been coding for 38 years.
|
| > Simple expressions are (in my experience) more
| readable.
|
| Simple is not the inverse of concise; there may be times
| when simpler expressions are more verbose, but that's not
| even approximately generally the case. "x2+1" and "x*2+1"
| and "add(pow(2,x),1)" and "x raised to the second power
| plus one" are equally _simple_ (or, at least, the later
| ones are not more simple), but they are progressively
| less _concise_.
|
| (It's true that expanding the space of concise
| expressions may require more complex _notation_ , and
| when the notation is unfamiliar, that creates a learning
| curve for learning the notation, but there's a reason
| people familiar with domains develop notations that
| support more concise expressions.
|
| > I understand it like this: to understand a complex
| expression you have to unpack it in your head to a
| simpler version in order to grok it.
|
| That's true of complexity of expressions, but again
| that's not the issue here. And concise notation expands
| the kind of expressions that can be grokked by pattern
| recognition rather than unpacking.
| marcus_holmes wrote:
| I think for terser expressions to be more readable, the
| reader has to be more context-aware and generally more
| immersed in the paradigm. There's an understanding of the
| language that needs to be acquired.
|
| Less terse language relies less on shared context, and
| thus is easier on newbies. There is less assumed
| knowledge, more things made explicit.
|
| > And concise notation expands the kind of expressions
| that can be grokked by pattern recognition rather than
| unpacking.
|
| I have this totally the other way. After years of coding
| in Go, I can parse "if err != nil" subconsciously and
| only ever deal with it if it's not that (e.g. if err ==
| nil). It's not concise, but it is very, very easy to
| read.
| erik_seaberg wrote:
| I can comfortably display maybe sixty lines on my screen.
| "if err != nil" wastes three of them, every time I do
| anything. I don't want explicit error plumbing for the
| same reason I don't want explicit stack frame setup when
| I call a function.
|
| Any worthwhile tool is going to be used for years, and
| you're only going to be newbie for a small fraction of
| the time. It's better to invest time learning a good
| notation than to force all the expensive experts to slog
| through a bad notation forever.
| AlexCoventry wrote:
| It's not so much a matter of reduced typing as that if
| you're invoking an operation many times, developing a
| concise notation for it can cut down on the noise it
| creates for a reader. It should be used very sparingly and
| heavily documented, though, for exactly the reason you
| outline.
|
| It really comes down to who you're writing the code for.
| For something like numpy, whose users will mostly be
| familiar with matrix notations, operator overloading
| enables a huge improvement.
| grayclhn wrote:
| Long expressions with matrix operations is a pretty
| standard example. When people talk about operator
| overloading in data science, they usually mean "standard
| operations on various arrays of numbers," which are defined
| in common libraries or the programming language. Not "I
| need to define my own ad hoc equalities."
| marcus_holmes wrote:
| yeah, I get this. If there are standard definitions of
| operations that everyone understands, that's fine.
|
| But I always think that maybe we should be using new
| operators for this, instead of overloading existing ones
| that have other, different, meanings in different
| contexts.
| grayclhn wrote:
| In a data science context, the key operations are math,
| so overloading makes a lot of sense and is massively
| helpful in implementing algorithms and equations. I go
| back and forth on the wisdom of some of the other common
| uses -- filtering, etc. In addition to the problems that
| have been mentioned, there are often hidden and
| infrequent but painful performance issues.
| marcus_holmes wrote:
| I often think that maths could use the same slap around
| the chops. Less arcane operators and symbols, more
| explicit function names please!
| grayclhn wrote:
| I consider it kind of important that the _notation_ for
| expressions like "A2" doesn't depend on whether A is an
| integer, real number, complex number, matrix, random
| variable, etc., (even if the results do) or what the
| specific domain is, but if you feel like it's important
| to embed all of that context in the exponent operator...
| give it a try :)
|
| (And whether "2" is integer, real, rational, complex,
| etc)
| vallas wrote:
| > With similar ease of development to Python Isn't the goal of
| general typed languages like Go or Rust to _run_ -not build-
| the scripts of softwares in data science for example? I wouldn
| 't compare Python and Go, it's different use case to me.
|
| While Go looks to be in the middle, Rust is at the opposite of
| Python and it must be a good to choice for building data
| software that run data scripts.
|
| > The [Go] lack of operator overloading => https://doc.rust-
| lang.org/rust-by-example/trait/ops.html
|
| > The [Go] lack of generics => https://doc.rust-
| lang.org/book/ch10-01-syntax.html
|
| > not being able to use algebraic operators for matrix and
| tensor libraries
| https://tensorflow.github.io/rust/tensorflow/struct.Tensor.h...
| s17n wrote:
| At Google, Go is mostly used for stuff that they would have
| used Python for in the past. Idk about the rest of the world.
| great_reversal wrote:
| Currently working as a backend dev in a mid-sized company.
| Current directive is a gradual migration to Go for backend
| services that used to be written in Python/Django.
| CameronNemo wrote:
| Why?
| AlexCoventry wrote:
| Go is a more restrictive language, which makes it
| slightly harder to create horrible codebases. It's also
| faster and a bit cheaper to deploy.
| micro_cam wrote:
| One of the original intents of go was to make a static,
| compiled language that felt familiar to python/ruby
| programers. This manifests as a really concise syntax (type
| inference via := etc) and a tight development loop enabled by
| fast compilation times (enabled by being strict about unused
| dependencies etc).
|
| I was for a time optimistic you could use it as your
| scripting language without much downside and get all the
| upside of compiled static types. Rust looks cool and I want
| to do a project in it at some point but at the moment I'm
| most optimistic about python with optional type annotations
| that are understood by compilers and alternative runtimes.
| mountainriver wrote:
| Operator overloading and the Go->C FFI are pretty big
| hinderances.
|
| Go just wasn't designed for this kind of work. Which is
| unfortunate because it brings a lot of great things to the
| table.
|
| Vlang is probably the closest spiritual successor that would
| work, or someone just needs to write a new language
| Ambix wrote:
| Really cool thing! When it will be ready for production use?
| tpmx wrote:
| Seems like there's a potential trademark risk if Google decides
| it wants to protect the Go trademark.
|
| https://news.ycombinator.com/item?id=20023137
| JediPig wrote:
| not even half baked. its a webpage with a single feature that is
| broken.
| iagovar wrote:
| If anyone is looking for an alternative to R or python, there's
| Julia already.
| CameronNemo wrote:
| Also Rust has a good datagrams library now, polars. Not as
| mature an ecosystem as Julia, but hopefully it improves in the
| future.
| hu3 wrote:
| I find Rust's borrow checker too clunky for exploratory work.
| It breaks my flow and imposes higher cognitive load. The slow
| compiler doesn't help either.
| mountainriver wrote:
| Yeah Rust is really close to what I want but I agree the
| borrow checker adds a bit too much overhead when dealing
| with data science.
|
| It seems like reference counting is probably the move here
| CameronNemo wrote:
| That is fair. I have not done enough exploratory work in
| Rust to comment. Maybe there are abalysis patterns that can
| avoid bumping up against the borrow checker.
| Gibbon1 wrote:
| I tend to think the innately slow compiler is basically a
| fatal mistake. Rust will never be able to be used for large
| projects. It's not so obvious now because everything it's
| used for is tiny.
| CameronNemo wrote:
| Hopefully some of the work out of cranelift, gccrs,
| and/or rust-analyzer can be used to speed up compilation.
| Gibbon1 wrote:
| Seriously one hopes. I think of projects in C++ that
| takes half an hour to compile, in rust they would take
| half a day or longer.
| c-cube wrote:
| What supports that statement exactly? If you split your
| big projects into crates it would recompile pretty fast.
| C++ can also take ages to compile (eg. compiling Firefox
| from scratch). Keeping your code modular to get decent
| compile times seems like a win win.
| sundarurfriend wrote:
| If this project can maintain Go's fast compile times and
| ability to make reliable, concice binaries, those would be two
| big pluses in areas where Julia is currently weak. That would
| make this a good choice in projects where those are high
| priorities.
| mountainriver wrote:
| I think what people want is all the great things Go brings to
| the table but just geared a little more towards data work.
|
| Julia offers a lot in the data world and not much in the
| engineering world.
| amelius wrote:
| Nobody in data science wants fragmentation. Therefore, any
| aspiring new platform would need to bring some serious benefits
| to the table. I'm not sure what they are here.
| yashap wrote:
| Go is a great language, but it seems terribly suited to data
| science. The popular data science languages are Python, R, Julia,
| and to a lesser extent Scala. They're all extremely flexible
| languages, where you can easily write high level
| abstractions/DSLs, and they all have very strong functional
| programming support, because data science tends to be extremely
| functional. They also tend to be very concise languages.
|
| 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.
| sabellito wrote:
| Not trying to start anything, but what's functional about
| Python? It doesn't have/support tail recursion, a strong type
| system, pattern matching, immutability-by-default for lists and
| dictionaries.
|
| From where I'm standing, python has some features that kinda
| look like functional programming concepts, but overall is an OO
| imperative language, like Ruby and many others.
|
| My understanding for its preference from the DS community is
| due more for its library support in that domain.
| Nican wrote:
| I think the appeal is with Jupyter [1] notebooks. Python is
| not about performance. Usually numpy (or other libraries)
| that does the heavy lifting on another language anyway.
|
| But having the Jupyter notebooks allows for intractability
| with the data. Make changes, and see how it affects every
| step after it.
|
| [1] https://jupyter.org/
| c3534l wrote:
| > strong type system, pattern matching, immutability-by-
| default for lists and dictionaries
|
| As a side note, its really interesting just how much the
| popular conception of "functional" has changed. 10 years ago,
| I don't think anyone would have listed any of those as being
| important or suggestive of functional programming. Nowadays,
| "functional" means "like Haskell" instead of "like Lisp." I
| think we need to be careful when we talk about functional
| programming because so many ideas have jumped the paradaigm
| and it means so many different things to different people.
| crazypython wrote:
| > a strong type system
|
| It's a myth that dynamic languages can't have strong types.
| Python aborts almost immediately whenever it can. For
| instance, adding a number to a string? Exception. Accessing
| undefined properties?
|
| Furthermore there's a language-standard static type checker,
| mypy.
|
| > pattern matching
|
| We have that in Python 3.10.
|
| > immutability-by-default for lists and dictionaries
|
| We do have tuples and frozendict.
|
| Arguably its implementations of functional features are much
| weaker than "truly" functional ones such as Lisp, Haskell,
| OCaML or F#.
| hda111 wrote:
| You can use basic functional concepts in Python but in Go
| it's not possible because it's a imperative language with
| only C and Pascal influences. However Python is to some
| extent influenced by Haskell (list comprehensions) and you
| can use functions that many FP languages have like reduce,
| map etc. For data science I can't imagine manipulating a data
| frame with a lambda in Go. It's the wrong language for this
| task.
| daturkel wrote:
| Python is not fully a functional programming language but it
| supports some functional patterns. There's a nice mini-ebook
| by David Mertz on functional programming in Python, and it
| used to be freely available but I can't find it at the
| moment. However, he wrote an article version here:
| https://developer.ibm.com/languages/python/articles/l-prog/
|
| Also, pattern matching is coming to python in 3.10. You can
| read about it here: https://www.python.org/dev/peps/pep-0634/
| nautilus12 wrote:
| Dry python returns library gets pretty close to feeling
| like scala cats. Unproductive diversions and all.
| tmpz22 wrote:
| IDK if its Go's problem honestly. Data modeling is hard. Its
| hard for a reason. If a language like python makes it _seem_
| easy, its still hard but your perception and attitude towards
| it has changed because some of the busy work has been taken out
| of it - possibly in a way that costs you down the road.
|
| Let's be honest programming languages are the punching bags of
| developers.
| kzrdude wrote:
| The env gop run shebang line is not posix-compliant; posix only
| requires support for a single argument in the shebang and this
| one has two arguments (gop run).
|
| </irrelevant unix nerd mumbling>
| nine_k wrote:
| POSIX is thirty three years old.
|
| Can we _please_ consider certain modest improvements?
| 10000truths wrote:
| The latest revision of the POSIX standard is only 4 years
| old.
| pjmlp wrote:
| And yet it is still all about writing CLI and server
| daemons, stuck in the early 80's timesharing computing
| world.
| [deleted]
| m45t3r wrote:
| There is env -S that supports multiple arguments. This was
| always an extension available in BSD I think, and it is
| available now in recent versions of GNU's env.
| d110af5ccf wrote:
| GNU Coreutils env supports the -S option as of v8.30. Ubuntu
| 18.04 LTS appears to be on v8.28, but 19.04 supports it.
| (https://stackoverflow.com/q/4303128)
|
| (Also, I didn't think the shebang was specified by POSIX at
| all? Am I wrong?)
___________________________________________________________________
(page generated 2021-03-27 23:00 UTC)