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

101–110 of 178 posts

Re: Go Modules in 2019

#101

Post by skybrian »

munificent wrote: post #70
jonahx wrote: post #60

Earlier quoted context omitted.

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, altho…

What I find particularly off-putting is that this attitude of superiority is sometimes married with objective incorrectness. If you're going to claim something is black and white, it should actually be black and white. &&, ||, switch, select, for, and while all do conditional execution in Go. So the rule is not "A language needs only one conditional control flow construct." The rule is really, "We didn't think a cond…

Yeah, I agree about it being off-putting. There's very little science in programming language ergonomics, so it all comes down to taste, right?

However, I wonder how much of this is a difference in substance and how much is about writing style? There is an older, authoritive style that has an implicit "in our opinion, of course" and sounds pretty grating these days.

I remember being taught in school to remove "I think" and qualifiers expressing uncertainty, under the theory that in an opinion piece, that's understood.

Especially these days when hyperbole is common, I prefer writers that have a humble writing style, but also try not to get hung up on stylistic differences.

Re: Go Modules in 2019

#102

Post by atombender »

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.

That's not true at all. A Go-modules-enabled project can import packages from a non-modules-enabled project that doesn't have Go.mod in it. This was always the case with Glide and Dep, too.

Re: Go Modules in 2019

#103

Post by yashap »

Felz wrote: post #90
jonahx wrote: post #60

Earlier quoted context omitted.

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, altho…

Why not have if/else be an expression in the first place, like Kotlin? n = if(expr) trueVal else falseVal No need to learn a separate ternary operator.

Quite a few languages do if expressions, and IMO they’re great. Simple syntax, readable and powerful. It’s crazy to me that any new language wouldn’t have them.

Re: Go Modules in 2019

#104

Post by zackmorris »

jonahx wrote: post #60
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, altho…

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 logic in a performant manner :-(

Re: Go Modules in 2019

#105

Post by aphexairlines »

kardianos wrote: post #86
jonahx wrote: post #60

Earlier quoted context omitted.

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, altho…

The authors of Go have stated they themselves sometimes miss the ternary form, but have seen it abused too much (deeply nested ternary). This isn't an insult to programmers, it is an option that clarity of code is more important then continence. Thus all if and for statements also require {} brackets.

In 10 years the expression form will be added to Go. It will be hailed as great progress, as adding clarity, and as unquestionably the Go way.

Re: Go Modules in 2019

#106

Post by iainmerrick »

Felz wrote: post #90
jonahx wrote: post #60

Earlier quoted context omitted.

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, altho…

Why not have if/else be an expression in the first place, like Kotlin? n = if(expr) trueVal else falseVal No need to learn a separate ternary operator.

Because the designers of Kotlin are more open to experimentation and new ideas.

Re: Go Modules in 2019

#107

Post by LanceH »

totalperspectiv wrote: post #89
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?

It's worth using. I do science things and use Go. It doesn't require much more mental overhead to write than a scripting language (possibly less once you're into it), it's pretty fast without arcane knowledge, it's easy to maintain, binaries are easy to deploy, and it has a super fast startup time unlike Julia, if you care about that. Overall, I'd highly recommend it.

I use it to push files around and possibly parse and move the data those files contain. But once it gets to strictly numerical things, the purpose built tools are the only real choice. Scientific libraries for Go are nearly non-existent, or just copies of fully formed libraries from somewhere else.

Re: Go Modules in 2019

#108

Post by 4ad »

eikenberry wrote: post #94
treve wrote: post #66

Earlier quoted context omitted.

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…

I think you mis-linked there. The email message with the denigrating comment about people who like syntax highlighting is here... https://groups.google.com/forum/#!msg/golang-nuts/hJHCAaiL0s... That was the day I dropped the mailing list.

I don't see anything denigrating there.

I disagree with Rob though, syntax highlighting is not juvenile, it's cargo cult programming.

Re: Go Modules in 2019

#109

Post by jonahx »

zackmorris wrote: post #104
jonahx wrote: post #60

Earlier quoted context omitted.

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, altho…

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 practice in Go. Have a problem with that? Expect a snarky comment about your priorities.

This can all be pretty frustrating when you've experienced the joys of more expressive languages.

Go has good concurrency primitives and is fast. That's what it's good at. Those are the reasons to use it. Temper your expectations accordingly.

Re: Go Modules in 2019

#110

Post by calcifer »

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…

> in module mode, using the vendor directory exclusively

But that's not what I'm asking. I want "go build" (with some flags) to use my fork (vendored if needed) for one library, and pick up all other dependencies from the module cache as usual. How do I that?

Because this is already possible in a vendor-only world; I just edit the code in vendor.

Post reply on HN