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

121–130 of 178 posts

Re: Go Modules in 2019

#121

Post by Merovius »

jonahx wrote: post #109
zackmorris wrote: post #104

Earlier quoted context omitted.

Oh man don't tell me these things. I haven't used Go yet in production, but the more I learn about the ways it diverges from functional programming, the more I doubt I'll ever use it. I was thinking I could write my own if(condition, true_case, false_case) method similar to the way it's done in spreadsheets, but Go also doesn't have macros or inline if/else expressions, so there is simply no way to emulate ternary lo…

Oh let's be very clear: Go is actively, explicitly anti-FP, anti-expressiveness, anti-brevity. Those are simply not its values. And any attempts to write Go in FP style will be considered unidiomatic Go. And the missing ternary will be the least of your problems. Do you enjoy `map` and `filter`? Sorry, the "go way" is to use a for loop every time. Reimplementing map on every type where you need it is considered best…

> Have a problem with that? Expect a snarky comment about your priorities.

Whereas your comment is completely devoid of snark.

Re: Go Modules in 2019

#122

Post by Merovius »

treve wrote: post #66
zemo wrote: post #59

Earlier quoted context omitted.

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…

Sorry about mis-remembering his name, but my point was a bit more nuanced. The frustration I had was not that certain features were missing, but I was met with a response that suggested that I was wrong for even wanting these features. It was a comment on my personal experiences of interacting with the Go community, not the language and its limitations. My hope wasn't that Go implements my every pet peeve, my hope is…

> Pike seems especially aggressive when interacting with people he disagrees with and this was for me indicative of the culture. It's been a few years though, so maybe by now I'm wrong!

FWIW, as much as I agree with Rob Pike on most things, I totally agree that he's abrasive and his way of phrasing things is often unhelpful (even though I think people also tend to read contempt into his brevity that isn't there). If it helps, I think he has realized that in the meantime and is largely staying out of public discussions for that reason.

Re: Go Modules in 2019

#123

Post by Merovius »

coldtea wrote: post #53
weberc2 wrote: post #44

Earlier quoted context omitted.

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

> ironically, the Go team has named their own/list forum "golang-nuts" despite that "not being the name of the language"

FWIW, go-nuts was already taken.

Re: Go Modules in 2019

#124

Post by Merovius »

weberc2 wrote: post #85
coldtea wrote: post #53

Earlier quoted context omitted.

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

"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'd say the most official thing said on the topic is this FAQ entry, which is quite clear on the matter: https://tip.golang.org/doc/faq#go_or_golang

(not saying Brad's comment isn't abrasive or rude. But it's not "factually incorrect")

Re: Go Modules in 2019

#125

Post by Merovius »

cyphar wrote: post #38
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.

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.

> 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

It seems this gets fixed in Go 1.12 though. AIUI you'll be able to set GOMODULES=on, unset GOPATH and just continue working as before.

Re: Go Modules in 2019

#126

Post by Merovius »

dagss wrote: post #51
zaphar wrote: post #40

Earlier quoted context omitted.

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

> Basically before go 1.11, it was impossible to just do

That's not true. It was always perfectly possible to do that, the code you build just couldn't import any libraries not installed in GOPATH. AIUI that is exactly the same as in other languages.

Re: Go Modules in 2019

#127

Post by jonahx »

Merovius wrote: post #120
jonahx wrote: post #88

Earlier quoted context omitted.

This would be a reasonable position: "While the ternary is often clearer, we chose to sacrifice expressiveness and brevity for the sake of preventing abuses, which we found were all too common." But that is not the claim being made in the FAQ. > Thus all if and for statements also require {} brackets. Indeed this rule seems to spring from the same philosophy. It is most certainly not a preference for clarity, though.…

> 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 clearer. But if you allow it, then you also open the door to nested ternaries, and foot shooting.

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

Re: Go Modules in 2019

#128

Post by Merovius »

stcredzero wrote: post #112
rwj wrote: post #83

Earlier quoted context omitted.

I'm not certain that Go is a great fit for this particular area. Others have mentioned generics, but I'd also worry that the lack of operator overloading is a weakness. There is a lot of Fortran out there, so operator overloading is not required, but I'd worry about the ergonomics of Go, especially given the strength of the other options.

The best course of action for Go on this front, would be to expose operator overloading of numeric operators, combined with a community expectation that this isn't to be used for anything but numeric operations. What would be the disadvantage of using a syntactic preprocessor to accomplish the same thing? We have an API for parsing golang. What if there was a way of marking certain files to be parsed and re-written w…

> The best course of action for Go on this front, would be to expose operator overloading of numeric operators, combined with a community expectation that this isn't to be used for anything but numeric operations.

I don't think this solves the issues. For example, I have yet to think of a way to overload `+` in a consistent and performant manner. E.g. think of `a += b` vs. `a = a + b`. Either you make them separate operators (in which case there's no guarantee they do the same thing - see for example Python, where they commonly differ) or you are overallocating in the common case.

Re: Go Modules in 2019

#129

Post by Merovius »

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…

This is exactly why I personally think efforts for language-specific package management in general are misguided. This is a solved problem in general-purpose package-managers (apt, dnf, pacman,…), for all their flaws. I don't understand why we need to re-invent that over and over again, including all the duplication of effort to re-package everything over and over again…

Re: Go Modules in 2019

#130

Post by Merovius »

pjmlp wrote: post #72
emersion wrote: post #64

Earlier quoted context omitted.

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.

> Same applies to Maven, in fact many enterprises forbid access to Maven central

"Maven central" implies there is a central repository though.

Post reply on HN