Toward Go 2 (or D needs to collect experience reports)

solidstate1991 via Digitalmars-d digitalmars-d at
Wed Sep 6 18:09:29 PDT 2017

On Wednesday, 6 September 2017 at 14:42:20 UTC, dimaria wrote:
> The highlights:
>> Our goal for Go 2 is to fix the most significant ways Go fails 
>> to scale.
>> Go 2 must bring along all those developers. We must ask them 
>> to unlearn old habits and learn new ones only when the reward 
>> is great.
>> Go 2 must also bring along all the existing Go 1 source code. 
>> We must not split the Go ecosystem. Mixed programs, in which 
>> packages written in Go 2 import packages written in Go 1 and 
>> vice versa, must work effortlessly during a transition period 
>> of multiple years. We'll have to figure out exactly how to do 
>> that; automated tooling like go fix will certainly play a part.
>> Today, what we need most is experience reports. Please tell us 
>> how Go is working for you, and more importantly not working 
>> for you. Write a blog post, include real examples, concrete 
>> detail, and real experience. And link it on our wiki page. 
>> That's how we'll start talking about what we, the Go 
>> community, might want to change about Go.
> I believe that if we ever want to see D3, we should start a 
> similar process and collect real world feedback about things 
> that are annoying on a daily basis.
> There have been many threads about "I want to have feature X" 
> in D and of course legendary threads like the one about 
> removing auto-decoding, but the aim of this discussion is to 
> identify things that bother you frequently or prevent you from 
> using D on a wider scale.
> Please see Russ's post for good examples. Blog posts or reports 
> on the wiki are very welcome.

I don't think a D2/D3 split is needed, just impose the fixes on 
the language step by step, which is easy in our current position. 
Only thing needed is some patching of already existing code. D3 
should only happen, when changes done to D2 will be harder to 
implement in the long-run, eg. widespread use of language 
functions (please, put DIP45 into effect, when it still won't 
break too much code!).

More information about the Digitalmars-d mailing list