I disagree, I think we are doing Go a disservice with this line of reasoning. I may be alone in this sentiment and that is fine.
tis 22 aug. 2017 kl 10:27 skrev Axel Wagner <axel.wagner...@googlemail.com>: > On Tue, Aug 22, 2017 at 9:56 AM, Henrik Johansson <dahankz...@gmail.com> > wrote: > >> I am sorry but you are missing the point. I think there already is a lot >> of _experience_ that doesn't need reiterating. >> > > This is a fundamentally flawed argument. By that logic, every language > should be identical to every other language, because all languages should > follow the same experience regarding the same features in the same way. > > Different languages have different flavors and different goals and so, > naturally, should give different weight to different problems and will > likely come up with different solutions. > > Experience reports are supposed to be specific to Go - how does go fail to > reach its own specific goals (mainly of enabling scaleable software > engineering)? On the topic of generics, for example, rust's flavor keeps > performance as its highest goal. Haskels flavor keeps a powerful static > type system as its highest goal. Python's flavor keeps terseness and ease > of use as its highest goal. > > Yes, experience says generics are a powerful, useful tool. However, it > doesn't necessarily show that it's a tool furthering Go's goals and if so, > which flavor is best to do that. That's what experience reports are > supposed to answer. > > >> My obsolete C++ knowledge is not enough to do a proper comparison but >> there are numerous experts available inside the core team as well as >> outside. >> Why do you insist on reiterating known knowledge? Sifon already existing >> experience instead of trying to coax written reports out of end users. >> >> Don't get me wrong, experience reports are very valuable but I think we >> are ignoring established knowledge. >> >> The examples you give about the actual implementation I can only >> superficially contribute to and it is of course an excellent grounds for >> testing. >> What makes you think that we can get to "the best" by any amount of >> discussion or anecdotal experiences? I prefer relying on the experts for >> the details. >> We _know_ that generics can be valuable, and the link above only >> reaffirms this. It doesn't give you any indication as to which of the 30 >> (??) implementations to pick. >> >> I really don't understand the need to over-do this whole experience >> thing. I get that it gives concrete insights into the day to day issues >> people have but if it also ignores decades of research then I strongly >> disagree with the approach. >> >> >> >> tis 22 aug. 2017 kl 09:12 skrev Egon <egonel...@gmail.com>: >> >>> On Tuesday, 22 August 2017 09:12:45 UTC+3, Henrik Johansson wrote: >>>> >>>> I am sorry Dave but you can ignore the needs of the many few as much as >>>> you want but the tiny things won't go away. >>>> >>>> There probably won't be any _written_ experience reports for most of >>>> the little things. The things that people live through and sometimes just >>>> have the time to email the list about a couple of times. It doesn't make >>>> them go away. The occasional "blog post in anger" happens of course and I >>>> have surely missed some things. >>>> >>> >>> People need to understand that experience reports are essential. We need >>> to reiterate it, until people start properly writing them. >>> >>> >>>> The sheer number of voices concerning generics is a huge experience >>>> report in my book as is error handling although very different in nature >>>> (but maybe related?). >>>> >>> >>> Let's say we take 30 different designs for generics or error handling or >>> enums or ... whatever feature X... then >>> >>> 1. What would be the deciding factor for what would be better for Go? >>> 2. Which of these features would be best to implement first? >>> 3. What would give us the best understanding how a particular design >>> would affect the community, packages and code? >>> 4. How can we understand which use-cases does that design cover and what >>> it leaves unsolved? >>> 5. What complementary features would be helpful? >>> >>> The mantra "this is a neat feature from [other language] I think it >>>> would be useful" seems to be often used as a hammer to quench any ideas >>>> that only stem from previous _experience_ in other languages. >>>> >>> What is Go if not a reaction to previous experience from C and C++? We >>>> could have drawn much more from previous experience. We did with >>>> concurrency and compiler speed for example. Why not with logging, generics >>>> or error handling? I would say that Go is first and foremost a reaction to >>>> previous experience and second an iterative model to hammer out the details >>>> and that is very good. We don't reinvent the wheel, we make faster and >>>> safer wheels. >>>> >>> >>> These cases can easily be written up as experience reports: >>> 1. example how you write your Go code and >>> 2. example how it can be written in C++; >>> 3. tell why the C++ felt better and why Go fell short. >>> >>> The problem is not lack of features... the problem is in understanding >>> the problem. >>> >>> >>>> Anyway I hope that not only huge "experience reports" are added to the >>>> scales when it really comes down to choosing the next big direction for >>>> this very nice language. >>>> >>> >>> Experience Reports don't have to be huge, from the wiki: >>> >>> >>> *The best experience reports tell:* >>> *(1) what you wanted to do,* >>> *(2) what you actually did, and* >>> *(3) why that wasn’t great, illustrating those by real concrete >>> examples, ideally from production use.* >>> >>> >>> If you can tell that in one paragraph and 3 links to >>> real-world-code-examples -- great, it will be a shorter read. >>> >>> *For example take a look >>> at https://varunksaini.com/blog/use-case-for-generics/ >>> <https://varunksaini.com/blog/use-case-for-generics/> -- short, sweet and >>> to the point* >>> >>> >>>> >>>> tis 22 aug. 2017 kl 00:41 skrev Dave Cheney <da...@cheney.net>: >>>> >>> I'd like to echo Egon's point. We were both in the audience for Russ's >>>>> announcement (although the video and the text are faithful reproductions) >>>>> and Russ clearly asked for examples where "Go fails to scale" as starting >>>>> points for a future version of Go. >>>>> >>>>> Starting from "this is a neat feature from [other language] I think it >>>>> would be useful" is eating the elephant from the wrong end. Russ asked for >>>>> written reports showing where the language does not live up to its promise >>>>> of developer productivity and production scalability. >>>>> >>>>> -- >>>>> 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. >> > -- 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.
