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

81–90 of 178 posts

Re: Go Modules in 2019

#81

Post by rwj »

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…

The community has gotten better. Early discussions were frequently marred hype, and it was often impossible to cut through the noise. However, talks given by the authors usually impressed me by being fairly even-handed, and open about the trade-offs that were taken.

Re: Go Modules in 2019

#82

Post by iainmerrick »

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…

Lots of people have made the same complaint/observation, though, and I don’t think they’re all just “rounding it off to one bit” as you describe.

I think they’re onto something, though as the GP notes, hopefully the situation is improving.

I’d flip your response around and suggest that in several cases, the correct fix is obvious and the core Go team’s insistence on extreme caution and “nuance” is misguided. GOPATH is a great example -- it’s just so obviously wrongheaded that I really don’t understand why it stuck around so long.

Another one that comes to mind, although this is quite old now, is the way early versions of Go would insist that the very last statement of a function was a “return”; you couldn’t do an “if foo { return x } else { return y }”, for example. It took a lot of pushing to persuade the core team to add some basic escape analysis, against insistence that it was some kind of nuanced feature with unpredictable side-effects, rather than a trivial thing that every other real compiler has to do.

Re: Go Modules in 2019

#83

Post by rwj »

stcredzero wrote: post #10
llimllib wrote: post #6

Earlier quoted context omitted.

It's not well-suited to scientific computing at all. I use and like Go for writing network servers and ETL processes. In a scientific context though, the type system is awkward in the extreme, there is essentially no library of modules, and the interactive visualization story is nonexistent. Python, R, Julia, even C++ would be better options IMO. (I'll clarify again: I like Go! I just think it's not well suited for t…

If one wants to be a pioneer and be one of the people who starts the movement, now is the time to jump in and make a name for yourself.

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.

Re: Go Modules in 2019

#84

Post by kasey_junk »

vhost- wrote: post #73
kasey_junk wrote: post #61

Earlier quoted context omitted.

The modules workflow is a wreck currently. Defer a while if you can.

care to explain why? I've been using it across all my projects just fine.

My biggest complaints are when something goes wrong. It will frequently silently fail or act like it succeeded. Diagnosing these errors has been a major time sink since I started using it.

Next have been oddities with vendoring workflows. Given previous decisions it seemed like the golang team was driving towards vendored solutions but with go mod they seem to have backed off of that position. The workflows with go mod are clunkier & less well documented. Unfortunately I’m (and my teams) are highly invested in vendored libraries.

We’ve also had trouble with it not playing nice with dependencies that have not taken up modules (and some that are unlikely to).

That’s not even to mention my problem with their design or the hamfisted way they have gone about it, which is something I just have to get past.

Re: Go Modules in 2019

#85

Post by weberc2 »

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

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

Re: Go Modules in 2019

#86

Post by kardianos »

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…

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.

Re: Go Modules in 2019

#87

Post by coldtea »

geodel wrote: post #77
coldtea wrote: post #50

Earlier quoted context omitted.

> I don't know. While no doubt some individual conversations have played out this way (law of averages and all that), I think this is a bad way to characterize the overall conversation. Most everything I've seen from the Go camp, including the new re-discovery of various wheels with the Go 2.0 proposals, felt like the parent describes to me. Never got the same from Rust, otoh.

See comments for Rust new website thread on reddit and elsewhere. Most Rust community seems mightily pissed off for all negative comments about their newly designed website. Besides Rust enthusiasts have reputation of trolling random people on internet who have unflattering things to say about Rust. Or try opening new thread on Swift forum on issues where decisions have been take. They will quickly put you in place a…

>Besides Rust enthusiasts have reputation of trolling random people on internet who have unflattering things to say about Rust.

I don't speak about Rust enthusiasts or even the Rust community at large, there are people like that in all languages (though indeed some communities might be better than others, but with large enough numbers of users of a language you get all kinds of people in a similar enough distribution).

I speak of the core team. Go's one has a vibe I don't get from Rust's.

Re: Go Modules in 2019

#88

Post by jonahx »

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.

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 a preference for consistency.

The philosophy is: "We're giving up expressiveness and brevity because in our experience most people can't be trusted to not shoot themselves in the foot."

This choice would be much more palatable if they were honest about it. But instead, they take the road of insisting that the verbose consistency is actually clearer, which it isn't, at least in many people's opinions.

Re: Go Modules in 2019

#89

Post by totalperspectiv »

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.

Re: Go Modules in 2019

#90

Post by Felz »

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…

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.
Post reply on HN