<p>I'm curious whether the Go 2 process is far enough to entirely change the look of the language or not. (I mean its syntax). I am just asking a factual question - not whether it's a good or bad idea.</p>
<hr/>**评论：**<br/><br/>lstokeworth: <pre><p>See <a href="https://blog.golang.org/toward-go2" rel="nofollow">the go2 blog post</a>.</p></pre>soapysops: <pre><p>Sure, language changes are okay. You need to have a reason though. A lot of language syntax is arbitrary, so most of Go's syntax probably won't change if only because there's no reason to change it. But if you can come up with a reason for some major change, then people are open to listening to your arguments.</p>
<p>I think people are misunderstanding what they said about backwards compatibility. What they said was we won't have a Python 2 -> Python 3 situation, where Python 2 code needs major manual work before it is useful in Python 3. There are many ways to allow language syntax changes such that we don't have a Python 2/Python 3 scenario.</p></pre>throwawaybeginr: <pre><p>thanks.</p>
<blockquote>
<p>There are many ways to allow language syntax changes such that we don't have a Python 2/Python 3 scenario.</p>
</blockquote>
<p>can you list them, please?</p></pre>soapysops: <pre><p>There isn't a list. Any possible change is unique and would require custom solutions. For example, some changes can be made using a tool like <code>go fix</code>, while some other changes might require support from the compiler - like it might have to support both versions of the syntax or something. But those are not the only two options.</p></pre>throwawaybeginr: <pre><p>okay, so other than those two options do you have any other options in mind? Thanks.</p></pre>deusmetallum: <pre><p>The Go devs have previously stated that 2.0 is pretty much going to look exactly like 1.9. They don't want to have a situation like in python where changing from 2 to 3 introduced so many changes that people simply haven't migrated their code.</p>
<p>Instead, the idea is that they want to do small changes all the time, and keep releasing. The next version may be called 2.0, or it may be 1.10, but there certainly won't be any big jumps.</p></pre>lstokeworth: <pre><p>The next version of Go is 1.10. <a href="https://github.com/golang/go/milestones" rel="nofollow">milestones</a>.</p></pre>throwlikepollock: <pre><p>Which is a bit odd, imo. Clearly we don't want a Py 2 -> 3 situation, but isn't allowing all Go 1 code to seamlessly run in Go 2 completely avoiding that situation?</p>
<p>I feel like we could add a lot of big changes on top of Go 1, making Go 1 basically a subset of Go 2. Regardless, we'll just have to wait and see what's coming haha.</p></pre>cameronjerrellnewton: <pre><p>It's not odd at all: See Java. 20+ years of backwards compatibility.</p></pre>Sythe2o0: <pre><p>But there's no reason to up a major version number without breaking changes. </p></pre>cameronjerrellnewton: <pre><p>I agree. Maybe go2 is more symbolic or representing an evolution of the language, kind of like when Java first received generics in 1.5. Maybe We can call it Go 1.20</p></pre>throwlikepollock: <pre><p>Well, I didn't say it was odd - I said in my opinion. I'm trying to understand.</p>
<p>So what's the reason for making Go 2 runnable in Go 1?</p></pre>throwawaybeginr: <pre><p>Thanks for that. answers my question clearly.</p></pre>arp242: <pre><blockquote>
<p>They don't want to have a situation like in python where changing from 2 to 3 introduced so many changes that people simply haven't migrated their code.</p>
</blockquote>
<p>Python 3 comes with a <code>2to3</code> tool which will actually deal with loads of the boring stuff for you. Package renames, function renames, and whatnot. Easy!</p>
<p>It's not necessarily the <em>quantity</em> of changes, more that some changes can't be easily migrated except by manually auditing your entire code base.</p>
<p>The biggest issue in Python 3 was of course entire <em>raison d'être</em> for "Python 3000" in the first place: the unicode change (everything else was tacked on later). No script in the world will ever be able to figure out if a bytes or unicode object was <em>intended</em>, so all the changes need to be manual. Ugh.</p>
<p>I don't care if Go 2 changes loads of things, as long as I can run a script to update my source tree <em>and</em> be guaranteed that it will update <em>everything</em>.</p>
<p>A simple example might be adding a new keyword; with the Go 1 comparability guarantee that can't be done because local variables or functions will override that and will cause problems, but Go 2 could do that. It would also be easy to write a script to tell us where those variables are used and automatically rename them (e.g. by adding an underscore or some such).</p></pre>Sythe2o0: <pre><p>There's been no indication that I've seen that it's made significant implementation progress. It's still in a planning stage, so syntax suggestions would presumably be accepted, but they'd probably prefer those suggestions in the form of an experience report. </p></pre>CountyMcCounterson: <pre><p>I wish they would just go back to the C way of</p>
<blockquote>
<p>int x = 7</p>
</blockquote>
<p>instead of</p>
<blockquote>
<p>var x int = 7</p>
</blockquote>
<p>which is just so stupid and unnecessary. They did it purely to be different when it is just weird and janky.</p></pre>robpike: <pre><p>You are incorrect. It was done for very good reasons and it is actually C's style that is the stranger one. See <a href="https://blog.golang.org/gos-declaration-syntax" rel="nofollow">https://blog.golang.org/gos-declaration-syntax</a> for a discussion.</p></pre>sh41: <pre><p>Also compare <a href="https://cdecl.org" rel="nofollow">cdecl.org</a> vs <a href="https://godecl.org" rel="nofollow">godecl.org</a>.</p></pre>CountyMcCounterson: <pre><p>You're just wrong on this, trying to be quirky or whatever and go against C when C is totally right on this.</p>
<p>For functions you can do whatever you want but variables should be declared type then name because it's clear and there's no nonsense syntax needed.</p>
<pre><code>int x = 7
</code></pre>
<p>It's just so clean and perfect.</p>
<p>You go into the huge long winded meme lines where you're like HA C I HAVE YOU NOW and then show off that if you construct a huge line of functions calling each other then it looks a bit janky and then you design the entire language around this when it isn't something people would even do more than a couple of times.</p>
<p>Here you go, here's a syntax that is enough of a meme for you to feel good about being different while actually looking somewhat good:</p>
<pre><code>int x = 7
x : = 7
function add(int x, int y) int {
*int x = New()
</code></pre>
<p>You declare variables like a normal person. You can auto type if you want. Functions look nice and you declare the type like Go rather than like C because that seems to work well. Pointers are declared like that because it looks kind of nice and clearly shows that it's a pointer at the front so it's unambiguous.</p>
<p>Look how clean that looks, it looks like an actual real person language that people with jobs would use rather than the current front end developer random syntax cobbled together full of exceptions because the rules don't really work.</p>
<p>Just move the language to that otherwise I'll have to cobble together my own shitty language or a compiler that compiles my slight syntax changes into Go and then uses the normal compiler and it will be terrible.</p></pre>Sythe2o0: <pre><p>No one but you is as vehemently interested in this change. You'll need to write your own compiler, sorry.</p></pre>
