Go 2, here we come

I’m hoping that <a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;19623" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;19623</a> 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.<p>It is bizarre to me that languages boasting built-in language-level data structures like lists, hashtables, etc are content to just leave us with the bare minimum support of <i>numbers</i>, being basically whatever the hardware thinks a number is. The semantics of integers and fractions are perfect, and everybody already knows them. On the other hand, overflows in int32’s are weird, and if your idea of a fraction is a floating-point number, then you can never have something like (5&#x2F;3)*6 evaluate to 10 exactly.<p>To be clear, I think fixed-width integers and floating-point numbers have their place, I just see no reason why they should be the default.

I&#x27;m pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I&#x27;m glad that what appeared to be a disingenuous &quot;let&#x27;s pretend to be hunting for the truth until people go away&quot; stance was actually really a hunt for the truth! Goes to show that you shouldn&#x27;t make snarky snap judgments.<p>As for all the folks claiming they&#x27;ll leave Go if it gets generics, it&#x27;s faintly reminiscent of Mac fanboys claiming PowerPC chips were the Very Best right up until this was obviously not true. C++ generics are a PITA in many ways, but you can be insanely productive in the STL without having to hand-roll everything and with good type safety.<p>Despite the pain, I&#x27;ve been amazed at how easily you can build up some really complex data structures as pretty much one-liners (&quot;Oh, I need a vector of maps from a pair of Foo to a set of Bar&quot;) that would either take a preposterous amount of code (or be a type-unsafe disaster waiting to happen) without generics.<p>Hopefully the final Go 2 generics proposal will capture some of this goodness without some of the horrifying C++ issues (error messages, bloat, sheer brain-numbing complexity).

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.<p>There&#x27;s like three or four different angles, all of which overlap. Some are official. Some aren&#x27;t. The unofficial ones seem more popular. They&#x27;re all kind of incomplete in different ways. And it was all such a frustrating migraine to try and figure out. I haven&#x27;t felt so viscerally aggressive about software like that whole experience made me feel in a long time.<p>I hope Go2 makes something concrete from the start and sticks with it, for better or worse.

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.<p>Haven’t tried it since.<p>Hope lots of this change to make the language more welcoming for Newcomers to the language.

Well I must say the Go team is certainly putting in the work to avoid a catastrophic major version bump (e.g. Python).<p>That said, any major additive change to Go, especially generics and&#x2F;or try&#x2F;catch will push me away from the language. If I need a well designed language, I have Rust. Go&#x27;s sell for me is it&#x27;s so naively simplistic it&#x27;s actually useful when your team members are idiots.<p>If they bolt on type variables, well that&#x27;s just a different language, and we&#x27;ll just end up on the hedonistic treadmill towards another Java. No thank you.

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.

I really like the humility in this part of the statement:<p>&gt; After almost 10 years of exposure, we have learned a lot about the language and libraries that we didn’t know in the beginning, and that was only possible through feedback from the Go community.<p>It&#x27;s so tempting to hold one&#x27;s project back until it seems perfect. And then, even worse, to defend it as perfect in the face of real-world feedback. I really appreciate it when smart people do their best, but in full recognition that a lot of things will be learned once real use happens.

Rob Pike had a good talk on the Go 2 process and a few of the proposals that went up on YouTube a few days ago:<p><a href="https:&#x2F;&#x2F;youtu.be&#x2F;RIvL2ONhFBI" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;RIvL2ONhFBI</a>

I hope they keep the changes reasonable and do not introduce any breaking changes. I like the language as it is now and I&#x27;m very productive in it.

I&#x27;ve been reading this proposal<p>&gt; #19113 Permit signed integers as shift counts: An estimated 38% of all non-constant shifts require an (artificial) uint conversion (see the issue for a more detailed break-down). This proposal will clean up a lot of code, get shift expressions better in sync with index expressions and the built-in functions cap and len. It will mostly have a positive impact on code. The implementation is well understood.<p>The proposal as far as I can make out says allow signed integers for shifts but panic if they are negative.<p>This seems like a step backwards to me pushing checking which the compiler made you do to runtime.<p>Personally I&#x27;d expect a negative shift to shift the other way, but that doesn&#x27;t seem to be a popular option with the team.

&gt; Go 2 will be much more community-driven.<p>Please no ...

I haven&#x27;t been keeping up with Go much these days but is there proper debugger support now? Or is it still a half-broken experience?

One question: As far as my knowledge told me, anything (or most?) interface{} in Go will be put to heap instead of stack. Will generics change that?<p>I really want to utilize those 2~4K stack spaces for the routines.

&gt; We are constrained by the fact that we now have millions of Go programmers and a large body of Go code<p>Are there really &quot;millions&quot; (plural) of Go programmers?<p>Sounds like a bit of an overestimate, no?

When I was young I thought Dijkstra published a paper called, &quot;go2&#x27;s considered harmful!&#x27;. I think the next version of Go should be Go3.

I know the comments aren&#x27;t meant for silly jokes but I&#x27;m very disappointed that there&#x27;s no &quot;Go 2 Considered Harmful&quot; jokes here

Non-go user here. So what are the most desired fratures from Go 2 in the community?<p>I remember something about generics not being supported.

It seems Go wants to have a more open development process, but it looks like all the decisions are ultimately under the purview of the &quot;Go team&quot;. Does the Go team include any community members? Or is this &quot;open process&quot; still essentially up to whims of a small group working at Google?

&quot;... keeping the language small and clean&quot; + Go Modules is the sweet spot for me.

I am torn apart between investing the next one year between Go and Rust. I want to do some cool systems level programming. Both seem to be very good at it. Go has additional advantages of being older (and may be wiser).<p>What does the hivemind think?

This blog post doesn&#x27;t answer likely the biggest of all questions: Will there be breaking changes? If so, how will those be handled?<p>&quot;As a rule of thumb, we should aim to help at least ten times as many developers as we hurt with a given change&quot; sounds like there might be breaking changes, but on the other hand Robert still talks about including new features in the Go 1 compatibility guarantee.<p>I&#x27;d love if the compiler would stay backwards compatible and packages &#x2F; modules could be pinned to a certain version, either during import or in the package &#x2F; module itself. Then one could write Go 2 code but still use packages which are not yet updated to Go 2. Personally I think that making breaking changes is a good idea, as it allows to clean up previous mistakes. However, Go should at all cost avoid incompatibilities like between Python 2 and 3.

I&#x27;m learning Go, just a naive question, why does Go put the variable type at the end of declaration, is this an absolute need? no other widely usage language does that, and it just feels odd to me.

I&#x27;m curious if making go an ISO standard was ever considered.

Am I reading this right that the list in the #Proposals header are the only proposals from the Go2 bucket that are being considered for 1.13?<p>I was hoping &quot;check&quot; would make the cut.

I really wish Go 2 can make dependency management easier.

Will we finally get a normal module implementation?

With that naming practice, it will probably become as hard to google problems as with AngularJS and Angular 2.

I&#x27;ve yet to see any mention of immutable data types, which I find I would use more than even generics.

Awaiting obligatory &quot;go 2 considered harmful&quot; YNews article.

So generics are in?

Wasn&#x27;t Go2 considered harmful :-?

Throw Semver OuT THE WINDOW!

GOPATH is the ugliness of Go. Can&#x27;t imagine that overhead for a modern PL.

Go 2 Considered Harmful:<p><a href="https:&#x2F;&#x2F;homepages.cwi.nl&#x2F;~storm&#x2F;teaching&#x2F;reader&#x2F;Dijkstra68.pdf" rel="nofollow">https:&#x2F;&#x2F;homepages.cwi.nl&#x2F;~storm&#x2F;teaching&#x2F;reader&#x2F;Dijkstra68.p...</a>

Big fan of both Go and also Rust. It is time we move beyond C and C++

I would love to have type-clases a-la Haskell (implicits with parametric polymorphism, which is dead-simple and well understood) and universal pattern matching everywhere, but this is, of course, just a dream.<p>I would love to have ML&#x2F;Scala-style syntax for curried functions and function definition via pattern-matching with guards, which is also, it seems, out of questions.<p>Actuall, the more of ML a strict language gets in - the better.<p>What is really funny is that Bell Labs did a lot of ML research, especially on stdlib, but Go team is ignoring everything which is not of the C flavour. Pity.<p>Again, ML is absolutely wonderful, and type-classes are the biggest single major innovation since Smalltalk.<p>It is better to lean towards ML instead of heading towards Javascript.

I smell the second coming of the Python 3 fiasco.

What&#x27;s that famous tag line? Oh, yes:<p>&quot;Use of Go 2 Considered Harmful&quot;.

Hahah oh no, I literally started learning Go last night. Now what?

I&#x27;ll be very sad if this goes the way of Perl 6

&gt;* 1. Allowing generalized unicode identifiers.*<p>I&#x27;m all for full support for unicode string manipulation.<p>But when ever are &quot;unicode identifiers&quot; a good idea? All kinds of BS decisions (normalization etc) for no good reason at all. Would you share code with identifiers written in RTL language? Chinese? Hieroglyphics?<p>And I&#x27;m saying this as someone who&#x27;s not a native English speaker.<p>If it was an APL dialect I&#x27;d see some reasoning, but what good does it do for Go?