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

31–40 of 178 posts

Re: Go Modules in 2019

#31

Post by jaredmosley »

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)"

Do you happen to have a link to the reddit post or to your article?

Re: Go Modules in 2019

#32

Post by tptacek »

cgag wrote: post #9
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…

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.

Re: Go Modules in 2019

#33

Post by cyphar »

skybrian wrote: post #17
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 think this is an example of rounding things off to one bit: either a feature is good or bad. Worse, people will round a language off to one bit: either it's great or terrible. Sometimes this is just due to defensiveness: someone uses a flaw to say the whole language is terrible and that gets a response from people who have learned to live with the flaw. Generally, if you back to the original statements you'll find…

> In the meantime, the "Go way" is about following common conventions for working within the language's limitations.

Except the problem is that "the Go way" changes in a way that breaks your previously-"working within the language's limitations".

An example of this that comes to mind is how the Go 1.5 vendor/ change was done. The community had rallied around several tools that would do vendoring and then would modify GOPATH to include vendor/ and would then symlink the current project into vendor/. All this required was a vendor/src. The Go 1.5 vendor/ implementation was almost identical but they removed the src directory -- which meant that pre-1.5 vendoring was now broken by Go (you can't really have two copies of your vendor tree in a repo and symlinks wouldn't work either).

There are a few other examples of this, but this one sticks out as it was the first feeling I got that the Go development team doesn't really care how the community has decided to work around a language defect. It literally would have just taken them one additional directory to not break every vendor/ project.

(Also, there has been absolutely no discussion with distributions -- as far as I'm aware -- on how packaging Go binaries should be done so we're all forced to come up with our own ideas. The Go modules stuff has considerations -- like builds requiring an internet connection -- that distributions would've had input on, but we didn't get asked about it.)

Re: Go Modules in 2019

#34

Post by [deleted] »

jaredmosley wrote: post #31
latch wrote: post #28

Earlier quoted context omitted.

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)"

Do you happen to have a link to the reddit post or to your article?

[deleted]

Re: Go Modules in 2019

#35

Post by tptacek »

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?

If you have a very well-defined problem and aren't doing much exploratory programming, Go works reasonably well for demanding math stuff. This describes a lot of cryptography work, and Go is a top-tier language for that. But for exploratory scientific and math programming, Go is pointlessly painful. Julia is a better option, and I would do Python Sage before I did Go, despite not loving Python.

Re: Go Modules in 2019

#36

Post by modernerd »

jaredmosley wrote: post #31
latch wrote: post #28

Earlier quoted context omitted.

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)"

Do you happen to have a link to the reddit post or to your article?

Not the author, but guessing:

https://www.reddit.com/r/golang/comments/33k8sp/gos_error_ha...

https://www.openmymind.net/Golangs-Error-Handling-Good-And-B...

Re: Go Modules in 2019

#37

Post by dana321 »

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.

Re: Go Modules in 2019

#38

Post by cyphar »

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.

I think a primary problem with the modules workflow is that you can't switch to it until all Go projects you work on switch to it. Plus, all of us have got our own GOPATH home-directory workarounds so there's no real point in switching anymore.

Re: Go Modules in 2019

#39

Post by icholy »

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.

Re: Go Modules in 2019

#40

Post by zaphar »

cgag wrote: post #9
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…

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.

Post reply on HN