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

51–60 of 178 posts

Re: Go Modules in 2019

#51

Post by dagss »

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.

GOPATH behaves very, very differently from PYTHON_PATH and CLASSPATH, it is not the same thing at all.

Basically before go 1.11, it was impossible to just do

    git clone ... somedir
    cd somedir
    # build code and run something
You had to instead make sure "somedir" ended up somewhere within a particular deep directory structure. That is what people mean when they say "GOPATH".

Re: Go Modules in 2019

#52

Post by spullara »

It is amazing that it took them this long to realize they were entirely wrong about how dependencies should be distributed. Since it was obvious from day 1 to most people from other ecosystems maybe they shouldn't have so much NIH. We'll likely get exceptions and generics soon as well. What a waste of time.

Re: Go Modules in 2019

#53

Post by coldtea »

weberc2 wrote: post #44
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)"

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

Such putdowns are a regular occurrence in Golang-nuts (ironically, the Go team has named their own/list forum "golang-nuts" despite that "not being the name of the language").

Re: Go Modules in 2019

#54

Post by mkozlows »

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.

Java, Perl, and Python all date back to the '90s. Yeah, that was a commmon pattern in the '90s.

Re: Go Modules in 2019

#55

Post by coldtea »

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?

>My primary use case is scientific computing, both data processing and interactive visualization.

If you actually have a primary use case of "scientific computing, both data processing and interactive visualization", ignore Go.

And rethink Python.

Julia can be used, but is still fringe.

R perhaps.

Re: Go Modules in 2019

#56

Post by vishvananda »

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?

I used go in machine learning contexts extensively while writing graphpipe[1]. Go is a fantastic language for servers, and distributed communication. Unfortunately, the lack of generics and dependence on interfaces and reflection makes writing things that deal with multidimensional arrays pretty terrible. See, for example, the janky conversion code in graphpipe-go[2] to convert a multidimensional slice into contiguous row-major arrays. Also, libraries that try to create a numpy eqivalent end up with uncomfortable interfaces due to inability to overload operators. I agree with some of the sibling comments that go 2 will help but probably won't make things particularly pleasurable. Rust would be a more interesting route but definitely doesn't have the adoption of go.

[1] https://oracle.github.io/graphpipe

[2] https://github.com/oracle/graphpipe-go/blob/master/helpers.g...

Re: Go Modules in 2019

#57

Post by emersion »

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.

Re: Go Modules in 2019

#58

Post by emersion »

spullara wrote: post #52

It is amazing that it took them this long to realize they were entirely wrong about how dependencies should be distributed. Since it was obvious from day 1 to most people from other ecosystems maybe they shouldn't have so much NIH. We'll likely get exceptions and generics soon as well. What a waste of time.

The way dependencies are distributed (ie. downloaded) won't change a lot, and as they say the distributed model is very important. Maybe you mean how dependencies are installed by the go command?

(As a side note, I don't think there are any plans for exceptions -- for good)

Re: Go Modules in 2019

#59

Post by zemo »

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…

the fact that you call Rob Pike "Erik Pike" really reads like the complaints of someone who doesn't do their homework and asks questions that have already been answered in many places.

Generics is a major tell, too, since the Go team's position on generics was always "generics are interesting but we don't know how to make them work well with Go's existing type system". See for example, this blog post from 2009: https://research.swtch.com/generic which references the FAQ answer to the generics problem here: https://golang.org/doc/faq#generics: "Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it."

so I can see why people who have repeatedly answered the same question for years, only to have their answer misrepresented for years, to be annoyed when people who haven't read any prior discussion bring up a point that has been already talked about ad nauseam.

Re: Go Modules in 2019

#60

Post by jonahx »

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…

Contemptuous scorn seems to be the officially-sanctioned strategy for responding to reasoned critique or even questions about "the go way" within the community.

My favorite example here is this arrogant dismissal of the idea that a one line expression, rather than a 5 line mutating statement, might be preferred for conditionally setting a value:

    if expr {
        n = trueVal
    } else {
        n = falseVal
    }
> The if-else form, although longer, is unquestionably clearer. A language needs only one conditional control flow construct. [0]

...

   n = expr ? trueVal : falseVal
"Unquestionably"

[0] https://golang.org/doc/faq#Does_Go_have_a_ternary_form

Post reply on HN