I think this way is more expressive for the developer. Removes boilerplate and reduces verbosity, which is more useful for scripting type applications like the ones Go+ is intended for.
Don’t think the OP said they prefer the standard, just that the examples provided didn’t really support the claim that It is clear and more readable.
Personally I think the more verbose form in Go is way more clear and readable, even if occasionally it feels a tad annoying to type over and over as the person writing it.
Go+ is a script-like version of Go, and (a script-like language / less stuff to type) is definitely one of the things you want when interactively analysing data. Some examples, gleaned from the readme and the tutorials folder:
You can put a shebang line in your Go+ script
Type annotations can be omitted in various situations
List comprehensions, to turn for-loops into expressions
but your Go+ code can import Go modules …
… and your Go+ code can be used as a Go module by Go code.
There’s probably more stuff that makes it easier to type than Go; but unfortunately I don’t know Go, so I can’t tell what the examples are improving on. Sorry!
No sign of learning from R or Julia, alas. Pandas and Jupyter were a big step forward for the Python data analysis ecosystem; but they are still a big step backward when you come from R or Julia data frames, or Rstudio + Rmarkdown notebooks (sorry, I don’t know the Julia equivalents here – VSCode + Weave.jl?).
Not sure if you know this, but Julia is a supported language for Jupyter notebooks. (That’s where the ‘ju’ comes from), so the Julia equivalents would be Jupyter notebooks as well!
Judging by the badges, there is/was meant to be a project called “NumGo+” that would be the “NumPy for Go+”, and which might be the home for that kind of stuff. But that repo has an init commit and nothing else.
There is, however, another project, GoNum, that does have the linear algebra stuff (but isn’t related to Go+).
I am curious about what this project is trying to achieve by this. Taking a language designed for simplicity and adding a bunch of features targeting as they say “data science” with them, thereby losing simplicity, while at the same time not being anywhere close to any similar project (Julia was mentioned), because there are opposing underlying design choices makes me wonder under what circumstances it could be useful.
I am so glad they implemented the
?operator, this will let me save so much repetition.Facts not in evidence.
I think this way is more expressive for the developer. Removes boilerplate and reduces verbosity, which is more useful for scripting type applications like the ones Go+ is intended for.
This is probably a matter of taste. Why do you prefer the standard Go way of handling errors?
Exactly my point! :) The claim doesn’t hold.
Don’t think the OP said they prefer the standard, just that the examples provided didn’t really support the claim that
It is clear and more readable.Personally I think the more verbose form in Go is way more clear and readable, even if occasionally it feels a tad annoying to type over and over as the person writing it.
So like Julia but … .
Please fill in the …
I think they’re trying to build ‘Pandas in Jupyter notebooks, but based on Go instead of Python’.
No sign of learning from R or Julia, alas. Pandas and Jupyter were a big step forward for the Python data analysis ecosystem; but they are still a big step backward when you come from R or Julia data frames, or Rstudio + Rmarkdown notebooks (sorry, I don’t know the Julia equivalents here – VSCode + Weave.jl?).
Not sure if you know this, but Julia is a supported language for Jupyter notebooks. (That’s where the ‘ju’ comes from), so the Julia equivalents would be Jupyter notebooks as well!
Coooool, I didn’t know! Thanks!
What about BLAS and LAPACK?
Judging by the badges, there is/was meant to be a project called “NumGo+” that would be the “NumPy for Go+”, and which might be the home for that kind of stuff. But that repo has an init commit and nothing else.
There is, however, another project, GoNum, that does have the linear algebra stuff (but isn’t related to Go+).
I am curious about what this project is trying to achieve by this. Taking a language designed for simplicity and adding a bunch of features targeting as they say “data science” with them, thereby losing simplicity, while at the same time not being anywhere close to any similar project (Julia was mentioned), because there are opposing underlying design choices makes me wonder under what circumstances it could be useful.
When all you have is a hammer …
Give me the list comprehension in normal Go and I’ll be happy.