<div>There is a dilemma of having to choose between:</div><div>A) getting stuck with bad names / apis / language issues forever</div><div>B) making painful breaking changes that breaks existing code</div><div><br></div><div>
See recent D threads for all the polemics this creates on (in)stability of D.</div><div><br></div><div>GO avoids this dilemma with the correct approach, IMO: automation of code transition.</div><div><div>See this article for details on gofix: <a href="http://blog.golang.org/2011/04/introducing-gofix.html">http://blog.golang.org/2011/04/introducing-gofix.html</a></div>
<div><br></div></div><div>gofix operates on the AST of the code and performs AST manipulations (no fragile 'sed' / regex based bash scripts!), followed by printing them back to the source code. This is made possible by gofmt, which formats source code.</div>
<div><br></div><div>Here's a snippet from the article:</div><div><br></div><div>"<span style="background-color:rgb(255,255,255);color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:13px;line-height:20.796875px">Gofix has already made itself indispensable. In particular, the recent reflect changes would have been unpalatable without automated conversion, and the reflect API badly needed to be redone. Gofix gives us the ability to fix mistakes or completely rethink package APIs without worrying about the cost of converting existing code."</span></div>
<div><span style="background-color:rgb(255,255,255);color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:13px;line-height:20.796875px"><br></span></div><div><span style="background-color:rgb(255,255,255);color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:13px;line-height:20.796875px">This is what we need for D if we want to avoid getting stuck in this dilemma.</span></div>
<div><br></div>