ons 23 aug. 2017 kl 08:37 skrev Florin Pățan <florinpa...@gmail.com>:
> 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. > > Not the same thing. Basing community work on "agreements" is good but not the same as claiming that not agreeing implies a lack of understanding. > If you happen to like Go, you like it because of that approach to it made > Go what it is today. > No, thats not why I like Go even if it came about using a certain process. Which I generally like btw. > 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? > Sure, I am a bit short in this but again my opinion is that experience reports wrt generics will only emphasize what is already known. That may in itself be a metric and of value. I don't have the time to write a proper proposal, it requires a lot of thought. As an end user who is a bit sick of reflective hoops and manual code generation to achieve type safety I would prefer the compiler to be able to do it for me. Moreover I think proper evaluation is impossible until an implementation is in place which of course is a terrible burden to place on the implementor. I have given up on generics in Go but I am still convinced it is a very good thing and out of the three sacrifices to be made I vote for sacrificing compiler speed although keeping it fast would also be good. > > > 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? > No I don't confuse them but often they have intimate knowledge of the respective pitfalls. > > > 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. > -- 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.
