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

71–80 of 178 posts

Re: Go Modules in 2019

#71

Post by sbinet »

tptacek wrote: post #63
sbinet wrote: post #45

Earlier quoted context omitted.

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.

These are things that are great for product development and devops and not in fact all that valuable in scientific computing, which is a reason why so much of it gets done in Python.

> These are things that are great for product development and devops and not in fact all that valuable in scientific computing

I disagree. Again, this may very well be science-domain dependent, but in High Energy Physics (where, finally, Python is recognized as a mainstream language, BTW) many -- if not all -- of the pain points that slow down undergrads, PhDs, post-docs and researchers at large, are these Go features.

yes, the time from "idea" to "little script that shows a bunch of plots" on a subset of the overall data is definitely shorter in Python (exploratory analysis is really really great in Python). but, at least for LHC analyses, python doesn't cut it when it comes to Tb of data to swift through, distribution over the grid/cloud, ... you die by a thousand cuts. and that's when you are alone on one little script. LHC analyses can see well over 10-20 people assembling a bunch of modules and scripts. You really long for a more robust to (automated) refactoring language than python, pretty quickly.

Re: Go Modules in 2019

#72

Post by pjmlp »

emersion wrote: post #64
pjmlp wrote: post #2

Nice overview, however a small correction to the statement about Maven repositories. Decentralized support has been a thing since the last decade.

What do you mean by "decentralized"? Do you mean someone can add a third-party repository and download packages from there? (Then it's been the case for other environments too) I think decentralized is meant as "there's no central repository" here.

Same applies to Maven, in fact many enterprises forbid access to Maven central, while curating an internal one.

Re: Go Modules in 2019

#73

Post by vhost- »

kasey_junk wrote: post #61
tptacek wrote: post #32

Earlier quoted context omitted.

I hated it at first but came around over time, to the point where I haven't switched to the modules workflow yet.

The modules workflow is a wreck currently. Defer a while if you can.

care to explain why? I've been using it across all my projects just fine.

Re: Go Modules in 2019

#74

Post by calcifer »

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 think this is a bad way to characterize the overall conversation.

> pretty much every Go-related conversation over at /r/programming seems to have someone arguing that it's literally impossible to build software in a language that lacks generics

Literally literally? Isn't your reply a "bad way to characterize the overall conversation" as well?

Re: Go Modules in 2019

#75

Post by pokstad »

emersion wrote: post #57

It seems like there's a mistake in the diagram. The "notary → mirror" arrow should be replaced with a "notary → go command" one, because the go command shouldn't trust the mirror when it comes to cryptographic hashes.

I think the mirror can pass through the public signature provided by the notary. That cannot be spoofed if you have a trust chain for the notary to ensure the mirror has not tampered with the module.

Re: Go Modules in 2019

#76

Post by laumars »

sbinet wrote: post #49
laumars wrote: post #7

Earlier quoted context omitted.

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...

I don’t want to create one for Go. It’s for a hobby language I’ve created.

I only mentioned it because the op discussed Go’s language server.

Re: Go Modules in 2019

#77

Post by geodel »

coldtea wrote: post #50
weberc2 wrote: post #12

Earlier quoted context omitted.

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.

See comments for Rust new website thread on reddit and elsewhere. Most Rust community seems mightily pissed off for all negative comments about their newly designed website. Besides Rust enthusiasts have reputation of trolling random people on internet who have unflattering things to say about Rust.

Or try opening new thread on Swift forum on issues where decisions have been take. They will quickly put you in place and close the thread.

I have yet to see a successful language where whiners are embraced with great enthusiasm.

Re: Go Modules in 2019

#78

Post by pokstad »

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…

Go modules still allow for changes to local copies. You are not required to use a proxy to use modules. Also, you can always fork a public project and use a replace statement in a module to redirect an import path to your customized module. Check out this related tool: https://github.com/rogpeppe/gohack

Re: Go Modules in 2019

#79

Post by w8rbt »

tptacek wrote: post #32
cgag wrote: post #9

Earlier quoted context omitted.

Honestly I got the impression no one ever liked gopath.

I hated it at first but came around over time, to the point where I haven't switched to the modules workflow yet.

Same here. Will wait until Aug 2019 when I have to think about it.

Re: Go Modules in 2019

#80

Post by calcifer »

icholy wrote: post #39
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…

Vendoring will still be supported.

How will that work with modules though? As in, how do you vendor a single library (that you want to make a fix to) while still building with module support? Right now, "module mode" is mutually exclusive with "vendor mode" and I don't think there are any plans to change that.
Post reply on HN