On Wednesday, August 23, 2017 at 6:45:57 AM UTC+1, Henrik Johansson wrote: > I may suffer from a "fundamental lack of understanding" about many things but > there isn't much to misunderstand in Russ blog post. I have also seen the > talk. I simply disagree wrt generics. I appreciate that he has thought a lot > about it and needs more feedback to feel it worth continuing. I disagree and > think that a real implementation (any?) is needed to evaluate.
How will you evaluate the implementation? Using what criteria? There are 4 proposals that Ian put together, but very clear examples. Which one of those do you consider adequate and why? Or if you don't, then why? > I, personally, don't think that agreement is a prerequisite for > understanding. This type of power speak is not worthy of this list, however > unintentional. > To go back in history for a bit, Go was built based on agreements. Agreements that once a problem presents itself, the solution passes the check for its core developers. For that to happen, understanding of the problem was essentially. If you happen to like Go, you like it because of that approach to it made Go what it is today. It might be easy to say: generics are a well understood problem, but that statement is just vague at best, and wrong. Yes, the need for generics is understood, else Ian wouldn't have tried to propose an implementation 4 times just himself. But what problems it should solve and what tradeoffs it should have it's not. That's where the experience reports come in. The more of those there are, the better a solution is agreed on and solves a more general problem. That can't happen without them. As I asked you earlier, how do you plan to evaluate any proposed implement? Why not share that with the world, with the team that will actually do the work of implementing this? > If you think that we don't as a community quickly denies the value of > suggestions then I must have been on a different list all these years. And it's so good they were shut down. Many of them were not solving any real problem but were creating more. In many cases the authors of those proposals were clueless as to the overall impact of their work. You said it yourself, the number of people that are good at language design (which I believe you confuse with compiler experts) is very small, so why not help them make the best decisions they can for the community of the language they created? > Technically it is correct that setting the value of X to zero or close to it > is not the same as disregarding it outright it still amounts to the same > thing. > > So much ado about nothing I will follow Egons example and but out. > > > > On Wed, 23 Aug 2017, 04:24 Linker <linker...@gmail.com> wrote: > > > 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 > <golan...@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 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...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > > > > > -- > > Regards, > Linker Lin > linker...@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...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- 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.
