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

111–120 of 178 posts

Re: Go Modules in 2019

#111

Post by kjksf »

pjmlp wrote: post #46
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.

The ones listed by you apply mostly as library search path, while go compilers required GOPATH to point to the project being compiled.

False.

You can put your code anywhere you want and `go build` and `go run` will work just fine.

It's only third party libraries that have to be in GOPATH, which is exactly a library (well, package) search path.

Re: Go Modules in 2019

#112

Post by stcredzero »

rwj wrote: post #83
stcredzero wrote: post #10

Earlier quoted context omitted.

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.

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 with function calls? It could be done with a file suffix, and this could be made fairly convenient.

Re: Go Modules in 2019

#113

Post by platinumrad »

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…

He's literally just making a joke riffing on 1 Corinthians 13:11.

Re: Go Modules in 2019

#114

Post by revel »

cgag wrote: post #25
revskill wrote: post #20

Earlier quoted context omitted.

Because setting environment variables is something most devs like to avoid.

No, because I have like 50 projects in ~/src and suddenly have to keep some of my code in ~/src/go/src/GitHub.com/cgag and that annoys me.

it's not just that large numbers of projects are a hassle, they make it harder to develop projects in isolation

Re: Go Modules in 2019

#115

Post by dragonwriter »

platinumrad wrote: post #113
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…

He's literally just making a joke riffing on 1 Corinthians 13:11.

No, while he does reference that (just quoting it directly, not “riffing”), it's not just a joke, it's a reinforcement of his earlier dismissal, in the thread, of syntax highlighting as a “juvenile” practice parallel to colored rods used to teach arithmetic to young children, which grown ups should not need or use.

Re: Go Modules in 2019

#116

Post by aeijdenberg »

kjksf wrote: post #111
pjmlp wrote: post #46

Earlier quoted context omitted.

The ones listed by you apply mostly as library search path, while go compilers required GOPATH to point to the project being compiled.

False. You can put your code anywhere you want and `go build` and `go run` will work just fine. It's only third party libraries that have to be in GOPATH, which is exactly a library (well, package) search path.

False only for very small values of code.

ie if your code itself is split into modules, they won't work (as they are imported by their full path, not relatively), and anything in your vendor dir is also ignored when used outside of a GOPATH entry.

Re: Go Modules in 2019

#117

Post by chimeracoder »

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.

Re: Go Modules in 2019

#118

Post by sbinet »

w323898 wrote: post #96
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?

In my opinion, the big rub for using Go in scientific computing is the lack of a REPL. The nature of Go essentially requires it to compile. On the plus side, compilation is very fast so iterating small code changes is practical. But it's still not nearly as nice as typing commands into the prompt and seeing what happens. Beyond that, Go is easy and performant. It's great for paralellizing workflows via concurrency an…

there are actually a couple of real interpreters for Go:

- neugram.io

- https://github.com/cosmos72/gomacro

here is a mybinder that used to use the former, and now uses the latter:

- https://mybinder.org/v2/gh/go-hep/binder/master

Re: Go Modules in 2019

#119

Post by eikenberry »

4ad wrote: post #108
eikenberry wrote: post #94

Earlier quoted context omitted.

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.

"Syntax highlighting is juvenile."

That clearly implies anyone who uses syntax highlighting is juvenile. I'd say calling someone juvenile is meant to be denigrating.

Re: Go Modules in 2019

#120

Post by Merovius »

jonahx wrote: post #88
kardianos wrote: post #86

Earlier quoted context omitted.

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 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 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. Clarity and lack of footguns seem directly correlated.

Post reply on HN