Hi,All!
We must remember the tragedy of python 3.x . We should not separate the
Go into 2 versions.
If we launch Go 2 whatever the situation is, we must drop Go 1 immediately.
On Wed, Aug 23, 2017 at 5:12 AM, sfrancia via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> As one of the few people who participates in the proposal review meeting I
> thought I'd shed some light on this.
>
> Go is intentionally simple. A lot of work has gone into the small balanced
> set of features. In fact prior to 1.0 a good number of features were
> removed as they weren't needed.
>
> The statement "As a community we are used to deny the value of some novel
> propositions." is just not true. It's not true about the community as a
> whole and it's not true about the project leadership.
>
> With each proposed feature we weigh the value of that feature vs the cost
> of adding it. We consider many costs including the cost to implement the
> feature, but also the cost of complexity, the cost of education and the
> cost that comes from transitioning to a new change. In many cases the value
> provided simply doesn't outweigh the costs, sometimes it does, but the Go
> project leadership never denies the value of any proposition.
>
> To make another clarification, in his keynote Russ both announced Go 2 as
> well as defining the process by which technical decisions are made for the
> Go project. The process outlined is not "the Go 2 process" but rather our
> process for developing Go and it applies to all future versions (including
> Go 1.10).
>
> Now to address some of the feedback in this thread:
>
> First, please read and re-read the blog post
> <https://blog.golang.org/toward-go2> on this. A lot of time and thought
> went into both writing that post as well as the process it conveys. Many
> things have been said that show a fundamental lack of understanding of that
> post.
>
> I want to call out a specific part of this post. While they are called
> "experience reports", what we are looking for is more specific than just
> experience.
>
> > Step 2 is to identify a problem with Go that might need solving and to
> articulate it, to explain it to others, to write it down.
>
> What is absolutely essential is that there is 1. a written *report* 2.
> that identifies *a problem* 3. that *the author is experiencing* 4. *with
> Go*.
>
> If it doesn't have those 4 components, then it isn't an experience report.
>
> Without an experience report accompanying it, a proposal lacks grounding.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
*Regards,Linker linlinker.m....@gmail.com <linker.m....@gmail.com>*
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
