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

131–140 of 178 posts

Re: Go Modules in 2019

#131

Post by Merovius »

xyzzy_plugh wrote: post #43
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.

Note that there's a difference between "central registry" and "central index". In particular, I don't see any downsides from what they are changing - godoc.org is already, for all intents and purposes, a central index, so I don't see how anything changes in that regard.

Re: Go Modules in 2019

#132

Post by spullara »

chimeracoder wrote: post #117
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.

> It is amazing that it took them this long to realize they were entirely wrong about how dependencies should be distributed. It didn't take "this long"; the Go team openly admitted the need for a better approach at the very first GopherCon back in 2014, nearly five years ago. (That was not the first time, either). It takes time to do all that work.

If you realize something is wrong a couple years in and it takes 5+ years to fix it, then that seems like a long time to me.

Re: Go Modules in 2019

#133

Post by Merovius »

jonahx wrote: post #127
Merovius wrote: post #120

Earlier quoted context omitted.

> It is most certainly not a preference for clarity, though. It is a preference for consistency. FTR, with "most certainly" you're committing the same fault your accusing the Go team here. You might not think it matters for clarity. I, at least, disagree. > in our experience most people can't be trusted to not shoot themselves in the foot. I don't understand the difference between this suggested phrasing and talking…

> FTR, with "most certainly" you're committing the same fault your accusing the Go team here. Fair enough. It's too late to edit. > I don't understand the difference between this suggested phrasing and talking about clarity. I'd argue you tend to shoot yourself in the foot if and only if you aren't clear about what you're doing. This is partially true but it's not that simple imo. In my OP, the ternary version is cle…

> Allowing single line if statements (as, eg, ruby does) also allows for clearer code, at the expense of consistency.

This (or rather allowing conditionals without braces) was what I was referring to. They are a foot-gun, because of the lack of clarity. It's a common source of bugs in C/C++ code that a developer thought they'd add a line of code to a conditional block or loop but didn't, because of a lack of braces. Requiring braces unconditionally make it always unambiguous and obvious what block a given statement belongs to.

Obviously YMMV - this is, as most discussions in programming, a matter of opinion. Which was my point :)

Re: Go Modules in 2019

#134

Post by axaxs »

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 was very active in the community at around the 1.0 release time, and probably am guilty of this, so late apologies. The problem in my eyes was that this was a new language that really solved a lot of problems in its simplicity from experience. And we all know design by committee is a disaster. The list was under a -constant- barrage of 'you should do X like language Y.' The general response from the community was along the lines of 'if you like language Y, you should use that, stop polluting the mailing list.' Essentially, it quickly got old with the constant asking of things, many ridiculous, that I feel probably a few good suggestions got thrown out with the weekly trash so to speak.

Re: Go Modules in 2019

#135

Post by mbo »

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…

What's wrong with Julia, a language purpose built for scientific computing?

Re: Go Modules in 2019

#136

Post by weberc2 »

Merovius wrote: post #124
weberc2 wrote: post #85

Earlier quoted context omitted.

"golang" is the official disambiguation, so it's factually incorrect to call people out for using that term. I don't follow that mailing list particularly closely, but I've not seen anything like this in the threads I have perused. To the extent that these things happen, the community should address this behavior.

> "golang" is the official disambiguation, so it's factually incorrect to call people out for using that term. I don't think "factually incorrect" is warranted. It's factually correct that the language is called Go. And while "golang" is a useful alternative for searchability and where "go" is taken, it is still a valid criticism to request using "Go" in natural language and prose. As for "official disambiguation", I…

Seems like you're splitting semantic hairs.

The language maintainers regularly and consistently use "golang" as a disambiguation:

* golang.org

* github.com/golang

* Twitter @golang and #golang

* golang-nuts

In this context, it seems pretty "official" and the rebuke "factually incorrect" or at least the rebuke applies equally to the maintainers.

That said, it was a single wayward comment and it is (in my experience) out of character. I want to acknowledge that it was rude and validate the person who was wrongly rebuked; I explicitly don't want to pick on anyone nor tempt the Internet to pile on.

Re: Go Modules in 2019

#137

Post by jonahx »

Merovius wrote: post #133
jonahx wrote: post #127

Earlier quoted context omitted.

> FTR, with "most certainly" you're committing the same fault your accusing the Go team here. Fair enough. It's too late to edit. > I don't understand the difference between this suggested phrasing and talking about clarity. I'd argue you tend to shoot yourself in the foot if and only if you aren't clear about what you're doing. This is partially true but it's not that simple imo. In my OP, the ternary version is cle…

> Allowing single line if statements (as, eg, ruby does) also allows for clearer code, at the expense of consistency. This (or rather allowing conditionals without braces) was what I was referring to. They are a foot-gun, because of the lack of clarity. It's a common source of bugs in C/C++ code that a developer thought they'd add a line of code to a conditional block or loop but didn't, because of a lack of braces.…

I'm aware of the reasoning. As you say, in C people would carelessly edit:

    if (condition)
      doSomething
to

    if (condition)
      doSomething
      doSomething2
So fair enough, you protect against that. You cannot therefore conclude that:

    if (condition) {
      doSomething
    }
is clearer or that 1 line if statements aren't clear. First of all, you've purchased your insurance at the cost of brevity. Which is quite a high price, especially when you have to use them constantly to write:

    if err != nil {
      return err
    }
and when it forces all of your 1 line conditional expressions to be 4 - 6 lines, per my OP.

And there are solutions that allow you to buy your insurance without such a high price. You can invert the position of the if, as ruby does. You could make a rule that when you don't have braces you have to write your statement on the same line. The point is this isn't the only way out. And clarity is not the same as preventing one specific kind of error, which occurs only in a context which could be changed as well.

Re: Go Modules in 2019

#138

Post by Carpetsmoker »

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

There are "I've used Go for a week and here are my strong opinions on it!" posted to reddit (and elsewhere) every week.

Frankly, it's just tiring; especially as a lot of the same points and misconceptions are repeated. Some points are valid, but it's repetitive at best. It would be like discussing Python's significant whitespace with inexperienced Python programmers every week. Sure, it's quirky and arguably not a good idea, but the discussion had been done a few times already.

Turns out that filtering stuff that uses "golang" instead of "Go" is actually a pretty good heuristic for determining if an article is worth reading. Is it perfect? Of course not; it's a heuristic.

Reading your article, this is exactly the sort of "been there, discussed that" kind of example. Your article isn't bad – I think it's mostly on-point – but it's also pretty much a repeat of what many others have said/discussed.

Re: Go Modules in 2019

#139

Post by geodel »

spullara wrote: post #132
chimeracoder wrote: post #117

Earlier quoted context omitted.

> It is amazing that it took them this long to realize they were entirely wrong about how dependencies should be distributed. It didn't take "this long"; the Go team openly admitted the need for a better approach at the very first GopherCon back in 2014, nearly five years ago. (That was not the first time, either). It takes time to do all that work.

If you realize something is wrong a couple years in and it takes 5+ years to fix it, then that seems like a long time to me.

In between community developed many solutions when official solution was lacking. So it's not like people were twiddling their thumbs for 5 years. Also check how long Java took to get official module solution. Work on that started in 2008 and solution was delivered in 2017.

Re: Go Modules in 2019

#140

Post by candiodari »

EdiX wrote: post #98
calcifer wrote: post #80

Earlier quoted context omitted.

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.

> Right now, "module mode" is mutually exclusive with "vendor mode" and I don't think there are any plans to change that. This is not true. If you pass -mod=vendor, or place it in $GOFLAGS, go will build something outside of GOPATH, in module mode, using the vendor directory exclusively. I wish it was the default, but only because it encourages people to not use vendor directories (which is a bad habit), not because…

Why are vendor directories a bad habit ? There just shouldn't be any GOPATH at all as far as I'm concerned.

Look in /usr/include. There you can see what's wrong with GOPATH, 5 years in the future. Now try installing 2 different versions of libraries.

I'll wait.

Post reply on HN