You are right that there is a benefit analysis to be made. I just think the problems are more known than you do.
On Tue, 22 Aug 2017, 12:08 Egon <egonel...@gmail.com> wrote: > On Tuesday, 22 August 2017 12:49:14 UTC+3, Henrik Johansson wrote: > >> The siphoning and "talking to other language designers" is of course >> related and I am sure that it happens. The community of compiler experts >> seems not huge. I am aware of Ian's attempts to draft some proposals and >> descriptions and that's what I am talking about. Experience reports will >> boil down to "it's messy and generics would help" and that's the most most >> developers can ever contribute. >> > > Then that's not an experience report... the important bit is the problem > and the problem domains. The "solution" for experience report is not > necessary and usually uninteresting. > > I would say, you can safely assume that for every problem people face, > the core team knows at least 10 different solutions. > > Just because the alias declaration was special and fairly unique does not >> mean there are no general prior knowledge available. I appreciate the >> special use case for it but it alone is not sufficient. The monotonic time >> issue as well which was handled brilliantly btw. >> >> We can and do know physics without knowing anything about medicine other >> than that medicine benefits from physics. I think it is fair to say that >> most if not all on your list would benefit from generics. >> > > Let's say you are a biomedical company and you had to invest in some > particular area in physics (e.g. material research, fluid dynamics, > nano-tech, mechanics, ...) -- which one would you choose? Where can be most > gained? How do you know that investment paid off? > > This is the purpose of experience reports -- to understand where core team > needs to invest their time. > > It's obvious that most features proposed have value to someone -- > otherwise they wouldn't have been proposed in the first place. And, I'm > sorry, if a proposer is unable to link to a single real-world example or > problem then I doubt it's value in practice. I think it's a bare minimum > requirement that any serious proposer can meet. > > I think I've thoroughly explained my position and understanding... and > will distance from the discussion for the time being. > > + Egon > > Still this is not about generics but how what goes into Go 2. >> >> On Tue, 22 Aug 2017, 11:17 Egon <egon...@gmail.com> wrote: >> >>> 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>: >>>> >>>>> 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. >>>>> 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. >>> 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.
