On Tuesday, 22 August 2017 10:56:52 UTC+3, Henrik Johansson wrote: > > I am sorry but you are missing the point. I think there already is a lot > of _experience_ that doesn't need reiterating. >
> 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. > Who will do the sifoning of that information? Known knowledge for whom? Which of that information is useful for Go programmers? For example, I've never written a graphics driver -- I assume there is a lot of known knowledge there, but I don't know what it is, and information about is difficult to get, because most people writing drivers are under NDA-s. > 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. > Of course not, but it eliminates some of them. Experience reports are not just about features... they are also things where we need more tutorials, better packages, better documentation, better tooling. They also serve as an indicator whether something has improved. An experience report from an expert in the field of course is even more valuable. It should be obvious that they discuss and talk with other language designers and experts in their field about particular features. > 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. > Because the "feature proposal" approach was tried and it didn't work properly. See alias declarations proposal (https://github.com/golang/go/issues/16339) for an example. The problem they are facing is cross-domain integration of features... so an expert or feature developed from years of experience in a particular field is not sufficient. Similarly a feature that has been developed from years of experience has also pieces that didn't work out so well. What are they? How can we find it out? For example which pieces of C++ templates could be replaced/removed due to concepts? Let's take a few domains that generics covers: 1. Machine Learning 2. Game Development 3. Business Intelligence 4. Statistical Analysis 5. Web Developers 6. Bioinformatics 7. Numerical Analysis 8. Audio Processing 9. GIS 10. Teaching 11. Image Processing 12. Business Processes 13. Databases ..... Now, all their needs to be condensed into one or two features that is suitable for Go and plays nicely with all other features. > tis 22 aug. 2017 kl 09:12 skrev Egon <egon...@gmail.com <javascript:>>: > >> 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...@googlegroups.com <javascript:>. >> 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.
