Experience reports are very valuable but there are many things that are
hardly possible to formulate as "something that hurt and needs to be fixed".
For example the dreaded generics, it doesn't hurt much but I think that,
for me, it is more that I am so happy with Go in general that I sort of
forget it.
It doesn't mean I wouldn't prefer the possibility to have an easier way to
express certain certain things generically. I do miss "streaming" stuff of
functional programming even if it is just a superficial part of it. Much of
it I can do without but to me Go would be better with it.

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).

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.

Reply via email to