Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go Modules in 2019

blog.golang.org

Post reply on HN
Print view View original

41–50 of 178 posts

Re: Go Modules in 2019

#41

Post by sbinet »

plg wrote: post #4

I really want to get into Go, I like that it's opinionated, I like that it's compiled, I like that it's garbage-collected, I like that coroutines are built-in. My primary use case is scientific computing, both data processing and interactive visualization. I know Julia is an option as well. For reasons I don't want to bother getting into I dislike Python. Thoughts?

others have already mentioned Gonum:

- https://gonum.org

Gonum is almost on par with _e.g._ NumPy/SciPy (most notably lacking: ODEs). So still ways to Go but it's getting there.

Go-HEP is my attempt to bring a few High Energy Physics oriented packages to particle physicists:

- https://go-hep.org

I've also written a few words on why I think Go is great for science:

- https://sbinet.github.io/posts/2018-07-31-go-hep-manifesto/

TL;DR: Go is great b/c it brings great s/w engineering practices and a s/w engineering-friendly environment to scientists.

Admittedly, generics will change how packages are written. So some code churn will take place when/if they land, but the Go community learned the lessons from Python2/3 and Perl5/6. Expect a better migration path.

Lastly, I guess the 2 remaining weak points of Go are:

- runtime performances sub-par wrt C++ or Rust

- GUIs (which may or may not fall into "interactive visualization")

That said, the Go community worked on a Go kernel for Jupyter:

- https://github.com/gopherdata/gophernotes

- http://gopherdata.io/

hth, -s

Re: Go Modules in 2019

#42

Post by tptacek »

sbinet wrote: post #41
plg wrote: post #4

I really want to get into Go, I like that it's opinionated, I like that it's compiled, I like that it's garbage-collected, I like that coroutines are built-in. My primary use case is scientific computing, both data processing and interactive visualization. I know Julia is an option as well. For reasons I don't want to bother getting into I dislike Python. Thoughts?

others have already mentioned Gonum: - https://gonum.org Gonum is almost on par with _e.g._ NumPy/SciPy (most notably lacking: ODEs). So still ways to Go but it's getting there. Go-HEP is my attempt to bring a few High Energy Physics oriented packages to particle physicists: - https://go-hep.org I've also written a few words on why I think Go is great for science: - https://sbinet.github.io/posts/2018-07-31-go-hep-ma…

Gonum is neat, but to the previously-made point about Go's type system making stuff more painful than it needs to be in this application: gonum's linear algebra is defined over float64 and int, which is problematic if you need arbitrary precision.

Re: Go Modules in 2019

#43

Post by xyzzy_plugh »

dana321 wrote: post #37

A centralized module index will be nice, i tend to end up searching github.com which leaves out all the other sites or locations that could have a module that solves my problem.

I very much do not want this. godoc.org has decent search and I've never had any complaints.

Re: Go Modules in 2019

#44

Post by weberc2 »

latch wrote: post #28
treve wrote: post #8

One of the thing that's always been a bit off-putting about the Go community and leadership is that it seemed that when I came across things that I perceived as flaws in the tooling or language, I often felt told off and was made to feel that it's me who is wrong for a variety of reasons. Examples of this include GOPATH, the package infrastructure, error handling, lack of generics. Rob Pike disagrees so I must be wro…

I wrote a blog post about the error handling. Someone put it on /r/golang (note the subreddit name). There were 22 comments, and the one from the Go developer was (and I quote): "Tempted to stop reading after the first word in the article. (The language isn't called Golang)"

That's a really disappointing story. Fortunately these sorts of attitudes aren't common in the Go community.

Re: Go Modules in 2019

#45

Post by sbinet »

tptacek wrote: post #42
sbinet wrote: post #41

Earlier quoted context omitted.

others have already mentioned Gonum: - https://gonum.org Gonum is almost on par with _e.g._ NumPy/SciPy (most notably lacking: ODEs). So still ways to Go but it's getting there. Go-HEP is my attempt to bring a few High Energy Physics oriented packages to particle physicists: - https://go-hep.org I've also written a few words on why I think Go is great for science: - https://sbinet.github.io/posts/2018-07-31-go-hep-ma…

Gonum is neat, but to the previously-made point about Go's type system making stuff more painful than it needs to be in this application: gonum's linear algebra is defined over float64 and int, which is problematic if you need arbitrary precision.

I guess it's scientific domain dependent. I've very rarely needed something else than float/double in my C++ days or REAL*8 in my F77 ones.

sure, when you need it, you need it. but float64 caters for a good 99% of my usual work day.

From a user POV, seamless installation of packages is a great boon. From a grid/cloud operator POV, static binaries are great too.

Re: Go Modules in 2019

#46

Post by pjmlp »

zaphar wrote: post #40
cgag wrote: post #9

Earlier quoted context omitted.

Honestly I got the impression no one ever liked gopath.

Pretty much every language has a GOPATH thing. CLASSPATH, PYTHON_PATH, PERL5LIB, ... I never really understand the hate here. It seems more like they didn't hate GOPATH specifically and more that they didn't like not having a package manager.

The ones listed by you apply mostly as library search path, while go compilers required GOPATH to point to the project being compiled.

Re: Go Modules in 2019

#47

Post by programd »

candiodari wrote: post #30

Maybe it's just me but I hate this option. Are we really, really trying to optimize the downloading of source code ? All 5 megabytes of it ? Why would you do that ? I regularly find myself in a position that this system would make impossible: I need a few custom changes in public available libraries. An extra method. A bugfix. What have you. This makes that impossible using the default method. What we want is consist…

I have to violently agree with this (consistent builds).

All the infrastructure with index, notary, mirror, etc. is nice, but at the end of the day you have to fetch some external code, verify it, lock it down in some vendor directory, and check it into your own backed up repo. Everything else is fluff.

If you're not doing this you're dancing with the devil and one day when you need to tweak some module or fix some bug, and the remote source is long gone, you will rue the day you depended on anything except your own source storage. And it will be 3 AM on Saturday, in some dismal server room, with no outside Internet connection, your customers screaming at you, and your phone battery dying, because Murphy's law.

For the purposes of software builds just pretend the rest of the Internet does not exist. Vendor everything, all the time, everywhere, and trust nothing.

Re: Go Modules in 2019

#48

Post by teacpde »

So the mirror will serve both the package and signed hashes, what if the package has been indexed in the central index but not yet signed by the notary?

Re: Go Modules in 2019

#49

Post by sbinet »

laumars wrote: post #7
jrockway wrote: post #3

Does anyone know what the story is for binaries generated by things your project depends on? npm versions them and lets you invoke them from the project with "npx"; I wish something like this existed for go. (protoc-gen-go is the main thing I want; if your global version gets out of sync with the version in go.modules, the generated protobuf doesn't compile.) I am glad to see that the go team is working on cleaning u…

On a vaguely related note, is there any decent documentation for writing a lang server. I've seen the official documentation by Microsoft and while it does seem a detailed reference, it's not great for someone who doesn't even know where to start in writing one.

this is being worked on:

- https://github.com/golang/tools/blob/master/cmd/golsp/main.g...

Re: Go Modules in 2019

#50

Post by coldtea »

weberc2 wrote: post #12
treve wrote: post #8

One of the thing that's always been a bit off-putting about the Go community and leadership is that it seemed that when I came across things that I perceived as flaws in the tooling or language, I often felt told off and was made to feel that it's me who is wrong for a variety of reasons. Examples of this include GOPATH, the package infrastructure, error handling, lack of generics. Rob Pike disagrees so I must be wro…

I don't know. While no doubt some individual conversations have played out this way (law of averages and all that), I think this is a bad way to characterize the overall conversation. From my viewpoint, the conversation is largely people coming from other languages telling the Go community its way is wrong while the people on the Go team argue that there are tradeoffs that they'd like to explore. For example, pretty…

>I don't know. While no doubt some individual conversations have played out this way (law of averages and all that), I think this is a bad way to characterize the overall conversation.

Most everything I've seen from the Go camp, including the new re-discovery of various wheels with the Go 2.0 proposals, felt like the parent describes to me.

Never got the same from Rust, otoh.

Post reply on HN