On Mon, Aug 21, 2017 at 9:01 PM, Henrik Johansson <dahankz...@gmail.com> wrote:
> There are most likely other things that are of similar status. The > context/value/bag thing seems like such thing to be more concrete. With a > stronger type system it could be much less obscure (not too much on my feet > here I admit). > Honestly, the context stuff would be the first thing that would come to my mind that would benefit from some experience reports (and I say that as someone who's not-an-experience-report on this was put in the wiki). So far, its criticisms seem to be mostly based on theoretical concerns - people arguing based on the mantra "more compiler checks are always better". The criticisms of context.Value not being type-safe or it being "magic" could very much use some experience reports. Has this ever lead to an outage/bug/…? Has it ever made a refactoring hard? FTR, not saying that it *didn't*, just that having actual empirical evidence for the problems would be much more helpful in replacing it with something else. > Perhaps this can be my Experience Report: There are some small things that > while not serious in isolation, they do add up. > > > mån 21 aug. 2017 kl 20:47 skrev Egon <egonel...@gmail.com>: > >> I must add these here: >> >> 1. https://www.youtube.com/watch?v=0Zbh_vmAKvk >> 2. https://www.youtube.com/watch?v=wpHggcP-L5M >> 3. https://blog.golang.org/toward-go2 >> >> Core team is asking for "Experience Reports"... which are not the same as >> "Feature Proposals". >> >> Many of the proposals I've noticed come without proper context and >> backstory -- in other words, why they were proposed in the first place. >> This already halts the problem solving and eliminates a ton of alternate >> solutions for the "unsaid problems". >> >> It's difficult to evaluate proposals without Experience Reports with >> regards to their possible value in practice. >> In some cases, there might be an elegant solution for the particular >> problem in Go that the proposer might not be aware of. >> In other cases, the initial code might be flawed making the proposal >> unusable. >> >> IMO, the main contributor of disagreements are 1. problem domain, 2. >> experience of different domains and 3. disagreement of values. >> Values are indirectly built-out-of 1. problem-domain and 2. experience of >> different domains. >> >> As such, without proper problem-domain and real-world-examples it's >> difficult to come to an agreement about a solution. >> Unfortunately, people usually aren't aware of the things they have picked >> up over time... be it starting with getting extreme diligence from >> assembly, >> or extreme concision in APL; complexity of distributed algorithms, >> playfulness of statistical analysis or speed of iteration from developing >> games. >> >> It's also problematic that many of these skills or systems seem >> "so-obviously-related-to-the-particular" problem at hand... >> which means, people leave them out. Other people of course imagine their >> own problems and situations... which leads to different "optimal solution" >> and disagreements and long-winded discussions, where people do not >> understand each other and try to convince each other. >> >> tl;dr; try to include your problem-domain and real-world-examples in >> discussions, so people can understand you. >> >> + Egon >> >> On Monday, 21 August 2017 20:03:15 UTC+3, JuciÊ Andrade wrote: >>> >>> If you guys allow me, I have a little concern about the Go 2 process. >>> I perceived some harsh debates when someone propose a new idea. That is >>> not the proper attitude. Please consider that the core team explicitly >>> asked for new ideas. >>> >> As a comunity we are used to deny the value of some novel propositions. >>> Conservatism is part of our culture. Usually the bar is very high to change >>> anything. >>> For Go 2 project to succeed, however, we should change that attitude for >>> a while. Now is time to allow people to complain, say whatever they want, >>> propose otherwise crazy ideas. Let's leverage that, let's appreciate a >>> differing point of view, a non obvious workflow, a strange idea. Let's keep >>> our ears open and our critical mouths shut. In due time critical assertions >>> will be welcome. >>> Keep in mind that not everyone in this list is a native English speaker. >>> Sometimes it is difficult to chose the right words. We don't want to loose >>> a good idea for a minor detail. >>> And, above all, let's keep polite. >>> >> -- >> 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.
