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

91–100 of 178 posts

Re: Go Modules in 2019

#91

Post by weberc2 »

calcifer wrote: post #74
weberc2 wrote: post #12

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. From my viewpoint, the conversation is largely people coming from other languages telling the Go community its way is wrong while the people on the Go team argue that there are tradeoffs that they'd like to explore. For example, pretty…

> I think this is a bad way to characterize the overall conversation. > pretty much every Go-related conversation over at /r/programming seems to have someone arguing that it's literally impossible to build software in a language that lacks generics Literally literally ? Isn't your reply a "bad way to characterize the overall conversation" as well?

> Literally literally?

Yes; I've challenged this as hyperbole and people double down.

> Isn't your reply a "bad way to characterize the overall conversation" as well?

I don't think so. My reply characterizes the overall conversation as a difference of opinion about whether or not Go's design choices are matters of tradeoffs, and I believe this to be accurate. I chose my example because it was exceptionally stark, but the point is that if such stark comments are made so frequently, surely there is a long tail of less-stark comments. Anyway, I don't want to belabor the point because we have no data and all we can do is conjecture and stir up bad feelings and likely a flame war, so let's not do that.

Re: Go Modules in 2019

#92

Post by teacpde »

emersion wrote: post #57

It seems like there's a mistake in the diagram. The "notary → mirror" arrow should be replaced with a "notary → go command" one, because the go command shouldn't trust the mirror when it comes to cryptographic hashes.

The hashes are signed by the notary, go command can get the hashes from anywhere and be able to verified they are signed by the notary.

Re: Go Modules in 2019

#93

Post by teacpde »

emersion wrote: post #62
teacpde wrote: post #48

So the mirror will serve both the package and signed hashes, what if the package has been indexed in the central index but not yet signed by the notary?

Maybe asking a hash to the notary will actually make the notary fetch and hash the package if it doesn't know about it yet? (Related: https://news.ycombinator.com/item?id=18717766 )

That works, but slows down the mirror? I guess it is okay since it should only happen once.

Re: Go Modules in 2019

#94

Post by eikenberry »

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…

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.

Re: Go Modules in 2019

#95

Post by superbaconman »

candiodari wrote: post #30

Maybe it's just me but I hate this option. Are we really, really trying to optimize the downloading of source code ? All 5 megabytes of it ? Why would you do that ? I regularly find myself in a position that this system would make impossible: I need a few custom changes in public available libraries. An extra method. A bugfix. What have you. This makes that impossible using the default method. What we want is consist…

Yeah. I feel like the modules work for the most part, but as soon as I want to develop cross project I have issues. Do I use the replace directive in my go.mod file? That's just gonna lead to merge issues whenever someone bumps a version number. Do I build using the vendor method that sounds like it's going to be ripped out at some point? How does my dev repo even get linked into that?

This whole gopath-less thing is a bit confusing to me. I wish the 'how to use packages' stuff was clearer.

Re: Go Modules in 2019

#96

Post by w323898 »

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 and compiling tools for distribution. So if you know what you want to do and need to scale up, it could be a great choice.

Re: Go Modules in 2019

#97

Post by weberc2 »

coldtea wrote: post #50
weberc2 wrote: post #12

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. From my viewpoint, the conversation is largely people coming from other languages telling the Go community its way is wrong while the people on the Go team argue that there are tradeoffs that they'd like to explore. For example, pretty…

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

I don't really want this thread to further devolve into a tit-for-tat. I'll just say that Rust's community has its bad eggs like any other, but that it does do exceptionally well at sympathizing with criticism. I'm mostly in "the Go camp", but Go's community can learn from Rust's here. On the other hand, for whatever reason, Rust is rarely approached with the same hostility that Go's community is--at least I don't see nearly the same percent of threads in /r/rust in the form, "I've been using Rust for 2 hours now and I haven't been able to figure out lifetimes and lifetimes are different than my language so lifetimes are stupid and no one can ship code with Rust!"

Re: Go Modules in 2019

#98

Post by EdiX »

calcifer wrote: post #80
icholy wrote: post #39

Earlier quoted context omitted.

Vendoring will still be supported.

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 it can't be worked around easily.

Re: Go Modules in 2019

#99

Post by Walkman »

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?

Go's main use case is for writing concurrent servers (mostly web servers) or daemons and command line applications that need to be really fast. Go is a generic programming language, but Python is "more generic", which I mean that you can go far more in a lot more domains (one of them is scientific computing and data analysis) than with Go. If you want to use go for data analysis I suspect that it would feel "a lot more work" to do the same thing than it would take in Python, mostly because it's a lower-level language and the ecosystem is not that huge than for Python yet.

Re: Go Modules in 2019

#100

Post by Walkman »

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…

Go works with Jupyter Notebook pretty well. It's a little bit complicated to set up, but it is the same REPL than you use for Python: https://walkman.cloud/s/dtoSfw753YSiMAs
Post reply on HN