• dimaria (11/28) Sep 06 2017 I believe that if we ever want to see D3, we should start a
• Kagamin (3/3) Sep 06 2017 The monotonic clock example is rather abysmal: they were deaf to
• Joakim (9/37) Sep 06 2017 I believe the core team is focused on D2 and isn't interested in
• Jesse Phillips (6/24) Sep 06 2017 I think D is already following those principles as it improves on
• solidstate1991 (8/36) Sep 06 2017 I don't think a D2/D3 split is needed, just impose the fixes on

dimaria <namhoang290305 gmail.com> writes:

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.

Kagamin <spam here.lot> writes:

The monotonic clock example is rather abysmal: they were deaf to 
predictions and when it broke half of the internet, they jammed 
in a hack.

Joakim <dlang joakim.fea.st> writes:

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 believe the core team is focused on D2 and isn't interested in 
entertaining thoughts about yet another breaking fork, especially 
after what happened the last time around.  As such, listing all 
such feedback will only be useful if you want to try and fix 
stuff in D2, it will most likely not lead to a D3 anytime soon.

Given D's current upward trajectory, they're probably right about 
maintaining that and pushing D3 for later:

http://erdani.com/d/downloads.daily.png

Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:

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 think D is already following those principles as it improves on 
D2's bugs and features. I think this is the right approach for D 
at this time. But re-evaluating what D3 should mean every couple 
years makes sense but will always have the thought that it is 
another D1/D2 split.

solidstate1991 <laszloszeremi outlook.com> writes:

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!).