Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 2, here we come

blog.golang.org

Post reply on HN
Print view View original

141–150 of 534 posts

Re: Go 2, here we come

#141

Post by Waterluvian »

As a newcomer to Go, by an immensely wide margin, the hardest, most frustrating thing, which soured the language for me, is whatever the heck package management is in Go.

There's like three or four different angles, all of which overlap. Some are official. Some aren't. The unofficial ones seem more popular. They're all kind of incomplete in different ways. And it was all such a frustrating migraine to try and figure out. I haven't felt so viscerally aggressive about software like that whole experience made me feel in a long time.

I hope Go2 makes something concrete from the start and sticks with it, for better or worse.

Re: Go 2, here we come

#142

Post by wwweston »

simias wrote: post #44
mempko wrote: post #38

Earlier quoted context omitted.

Perl6 is amazing! Yes it took a while. Yes it doesn't have the same recognition as perl 5. Yes it's crazy. But it's crazy in fun sort of way.

So are chicken scheme and GNU Forth. The problem is that the Perl ecosystem and community are a shadow of what they used to be in the heydays of Perl 5. I used to write a lot of Perl but I wouldn't really recommend it to anybody these days, be it version 5 or 6.

"Shadow of what they used to be" is a nice gig if you can get it when the "used to" part was basically the scripting language.

Perl is still in top 20 programming language lists. That's arguably "below the fold" of search results, but hey, so are Lua and Haskell.

The Perl Community... I don't know exactly what you mean. I might believe that size in terms of active work on a growing number of modules has dropped; but I don't believe the quality of participation has. Even though I haven't written a line of production Perl in well over a decade I still like checking in every so often to see what they're talking about.

And for those for whom all you know about Perl 6 is its delayed arrival and related woes, I can guarantee there's more interesting things to be seen.

Re: Go 2, here we come

#143

Post by nathanaldensr »

atombender wrote: post #70
infogulch wrote: post #23

I really really hope Go 2 can do something about `context`. Context is the biggest hidden wart of Go. We need the capabilities of context in different packaging.

This doesn't seem to be a popular opinion, but I agree. It's such a pervasive functionality in concurrent programs that it really should be a built-in aspect of a goroutine. The problem with context isn't necessarily the interface, it is that it is "viral". If you need context somewhere along a call chain, it infects more than just the place you need it — you almost always have to add it upwards (so the needed site g…

Forgive me since I've never used Go, but this sounds similar to having to add the async keyword to methods in C# all the way up the stack once you attempt to use an async method, as well as having to pass CancellationTokens down the stack to support cancellation. I've noticed it pollutes code with a lot of ceremony that I wish had been added to the runtime itself. Is this what you're talking about?

Re: Go 2, here we come

#144

Post by infogulch »

Teckla wrote: post #69
infogulch wrote: post #23

I really really hope Go 2 can do something about `context`. Context is the biggest hidden wart of Go. We need the capabilities of context in different packaging.

Having to manually pass context through so many functions in code bases is definitely not ideal.

It doubles the surface area of every library that deals with anything related to IO, and forces middle libraries that don't and shouldn't care about context to double their surface area just to support connecting their consumers to their upstream providers. "not ideal" is an understatement.

Re: Go 2, here we come

#145

Post by tpfour »

Waterluvian wrote: post #141

As a newcomer to Go, by an immensely wide margin, the hardest, most frustrating thing, which soured the language for me, is whatever the heck package management is in Go. There's like three or four different angles, all of which overlap. Some are official. Some aren't. The unofficial ones seem more popular. They're all kind of incomplete in different ways. And it was all such a frustrating migraine to try and figure…

My only experience with Go was around 2012-2013. It was fun, but I did not bother sticking with it. The forced directory structure was a little bit annoying and I found myself writing interfaces for everything. I'm sure people will say it's my fault as a programmer, but it turned me off from the language.

Re: Go 2, here we come

#146

Post by fwip »

treis wrote: post #48
asien wrote: post #26

I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows. Haven’t tried it since. Hope lots of this change to make the language more welcoming for Newcomers to the language.

>I tried Go a while ago. I was hooked by the performance , the community around it and vendors support ( AWS , Heroku , GCloud etc...) but I got quickly fed up by the awkward package management system, the weird syntax and the horrible idea of $GOPATH, especially on Windows. My experience was similar. In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those…

I think the closet Go equivalent of 'byebug' would be delve[0].

It's got more of a learning curve than a REPL, but very powerful. Editor plugins for Go also tend to have good convenience support for delve, making using it less painful. For example, vim-go[1].

[0]: https://github.com/derekparker/delve/blob/master/Documentati...

[1]: https://github.com/fatih/vim-go/blob/master/doc/vim-go.txt#L...

Re: Go 2, here we come

#147

Post by llimllib »

geezerjay wrote: post #95
llimllib wrote: post #90

Earlier quoted context omitted.

Go modules are extremely suitable for current work; they're as un-risky as anything labelled "experimental" could be. I've been using them for a boring professional application for about 4 months now, and there are no hassles with using them.

> they're as un-risky as anything labelled "experimental" could be. Yes, that's exactly the point, and why any decision to take a hard pass is more than obvious.

I don't understand what you mean, sorry

Re: Go 2, here we come

#148

Post by cdoxsey »

Waterluvian wrote: post #141

As a newcomer to Go, by an immensely wide margin, the hardest, most frustrating thing, which soured the language for me, is whatever the heck package management is in Go. There's like three or four different angles, all of which overlap. Some are official. Some aren't. The unofficial ones seem more popular. They're all kind of incomplete in different ways. And it was all such a frustrating migraine to try and figure…

Go modules are available in go 1.11 today. If you're envisioning another new pkg management solution besides that, I don't think that's going to happen.

Re: Go 2, here we come

#149

Post by infogulch »

nathanaldensr wrote: post #143
atombender wrote: post #70

Earlier quoted context omitted.

This doesn't seem to be a popular opinion, but I agree. It's such a pervasive functionality in concurrent programs that it really should be a built-in aspect of a goroutine. The problem with context isn't necessarily the interface, it is that it is "viral". If you need context somewhere along a call chain, it infects more than just the place you need it — you almost always have to add it upwards (so the needed site g…

Forgive me since I've never used Go, but this sounds similar to having to add the async keyword to methods in C# all the way up the stack once you attempt to use an async method, as well as having to pass CancellationTokens down the stack to support cancellation. I've noticed it pollutes code with a lot of ceremony that I wish had been added to the runtime itself. Is this what you're talking about?

Yeah, context is basically a cancellation token with the same downsides and a bunch of unrelated features piled on (because it came from a bunch of people needing to work around limitations getting together and deciding to put all their hacks in one place, but I digress). But from a certain perspective all functions in go are async by default, so we get to dodge that one.

Re: Go 2, here we come

#150

Post by gauravphoenix »

nerdwaller wrote: post #125
gauravphoenix wrote: post #111

I really wish Go 2 can make dependency management easier.

Have you tried go modules since 1.11? It's significantly simpler now than it was before.

I haven't yet. I hope a good eco-system develops around them. My biggest gripe is that there are just too many approaches in Golang when it comes to the dependency management.
Post reply on HN