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

241–250 of 534 posts

Re: Go 2, here we come

#241

Post by scott_s »

the_clarence wrote: post #104
joppy wrote: post #27

I’m hoping that https://github.com/golang/go/issues/19623 will come through, and we’ll get a native “true integer” type (and hopefully a rational one as well, though maybe this is pushing it a bit). This is really something that should be implemented at the language level, so that “int” can become a true integer, yet still remain efficient in many cases. It is bizarre to me that languages boasting built-in language-l…

Why oh why do people want a value to have different bounds depending on which system it is used? This is a source of huge confusion and why people stick to uint8 and other precise types

It's a rational practice when your language allows casting pointers to integers. Since the size of the pointer itself will vary based on the underlying architecture, you need an integer type which will also vary based on the underlying architecture.

Re: Go 2, here we come

#242

Post by sieabahlpark »

geezerjay wrote: post #80
smudgymcscmudge wrote: post #28

Earlier quoted context omitted.

If $GOPATH was your biggest complaint, now may be a good time to give it another look. As of 1.11, there's an experimental feature called go modules that lets you avoid using GOPATH. I believe it's going to be non-experimental starting in 1.12.

> there's an experimental feature That's not a feature but a fix for a design problem, and currently the only fix is an experimental one. For those seeking to invest their time learning a professional tool, that's a whole pile of no-nos that naturally point to a very hard pass.

I don't understand the issue with language improvements, should we only use languages that were perfectly designed to start? Like JavaScript?

Re: Go 2, here we come

#243

Post by zik »

tpfour wrote: post #145
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.

The new module system removes $GOPATH and the forced directory structure.

Re: Go 2, here we come

#244

Post by sieabahlpark »

simfoo wrote: post #66
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.

Same here. For me it was primarily the syntax. So many people think that syntax is something you get used to, but I don't. Syntax matters a lot for me, and the way Go does it just isn't compatible with my brain. Regular grammars are great for parsers. But really, having an easy to read (conceptually!) language is way more important imho. But call me crazy when I say that I like C++ and can read it effortlessly :)

If you like c++ then you just haven't given Go enough time to sink in.

It reads more left to right then right left like c++.

Re: Go 2, here we come

#245

Post by treis »

vram22 wrote: post #103
treis wrote: post #48

Earlier quoted context omitted.

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

> In addition to those, I found I really missed a REPL console and moreso something like byebug that RoR has. For those that aren't familiar, byebug lets you put the command "byebug" anywhere in your code that opens an in context REPL. It's enormously helpful for hard to figure out bugs. This is like comparing apples and oranges, or at least, like comparing apples and apple-orange hybrids :) Just saying that Rails (R…

>This is like comparing apples and oranges, or at least, like comparing apples and apple-orange hybrids :)

>Just saying that Rails (RoR) has a command like byebug that opens an in-context REPL, seems to ignore the fact that compiled languages like Go catch many errors earlier, at compile time, so you don't even need an in-context REPL or a debugger to find those.

I definitely liked the type system of Go and the compile time errors it found. It gives you a lot of peace of mind and reduces some errors. However, those errors aren't the things I use byebug for. Byebug is for things like figuring out why your code went down Path A when you expected it to go down Path B. Or if you don't know how to do something it's a sandbox to try a few different things until you get the output you were looking for.

Re: Go 2, here we come

#246

Post by christophilus »

wishinghand wrote: post #227
13415 wrote: post #102

Earlier quoted context omitted.

This 'question' is bound to go up in flamewars, but here is an honest and unbiased answer by someone who has taken a look at nearly every language on the planet (a hobby) and thinks that both languages are a bit crappy from a general programming language perspective but quite usable in practice. Go is good to get things done quickly. It has a vast ecosystem and super-fast compilation. It's like a modern BASIC, but mo…

> It's fast enough for most everyday tasks except for real-time audio processing and high end gaming Have any new languages popped up in either of those spaces or does C++ still reign supreme?

Zig seems like a possible contender.

Re: Go 2, here we come

#247

Post by icholy »

AnimalMuppet wrote: post #226
bsaul wrote: post #97

Earlier quoted context omitted.

There must be some very angry people downvoting on this comment section today. Go is very opinionated and it's quite obvious that its original design being so radical (no class, no inheritance, no generics, no macro) was only possible because it was designed by a few very experimented people with a very specific goal in mind. I'm also worried about how being "community driven" will change the philosophy of the langua…

I think "community driven" means less than you fear. I think it means that community feedback is used to push the language in directions that scratch some of the major community itches. That seems perfectly reasonable to me - more reasonable than making changes in a vacuum, in fact. But I don't think that they're going to let the community run wild and completely change the character of Go. I think they're looking fo…

I hope you're right

Re: Go 2, here we come

#248

Post by dolmen »

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…

I have written the 'contextio' package that may be useful to you. It provides io.Reader and io.Writer wrappers that handle context cancellation. This allows to transparently add optinal context cancellation awareness to routines that work with I/O without injecting context as argument.

Doc: https://godoc.org/github.com/dolmen-go/contextio Example: https://godoc.org/github.com/dolmen-go/contextio#example-pac...

Re: Go 2, here we come

#249

Post by icedchai »

tigershark wrote: post #88
joppy wrote: post #27

I’m hoping that https://github.com/golang/go/issues/19623 will come through, and we’ll get a native “true integer” type (and hopefully a rational one as well, though maybe this is pushing it a bit). This is really something that should be implemented at the language level, so that “int” can become a true integer, yet still remain efficient in many cases. It is bizarre to me that languages boasting built-in language-l…

I am misunderstanding or really go is using the ‘int’ type that can be 32 or 64 bit depending on the system that it runs on??? If this is the case I think that is crazy and I can’t think of any useful use case for it. If it’s not the case then please explain me what that proposal is really about...

Yeah, sounds crazy. It only worked for C for 40+ years...

Re: Go 2, here we come

#250

Post by joobus »

ilovecaching wrote: post #9

Well I must say the Go team is certainly putting in the work to avoid a catastrophic major version bump (e.g. Python). That said, any major additive change to Go, especially generics and/or try/catch will push me away from the language. If I need a well designed language, I have Rust. Go's sell for me is it's so naively simplistic it's actually useful when your team members are idiots. If they bolt on type variables,…

I feel the same way. By the time Go2 releases, I hope Rust has solidified its async/await syntax, and Rocket can build on stable.
Post reply on HN