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.
