Discussion
In my interactions with other go library maintainers I realized I have really strong opinions about how code should look like, and I have a really low patience threshold for explaining why that is.
I guess I've been long enough out of the loop of developing in teams, that I'm no longer able to patiently explain why I prefer certain ways of doing things.
In the end after a week of back-and forth I'll have to stop massaging the PR I was proposing due to irreconcilable differences between how me and the maintainer view the absence of a "thing" vs the "thing" being empty.
I won't say I completely wasted my time, but it's still a little unpleasant when reading the same specification leads to such different interpretations. Oh, wait... I've seen this with ActivityPub too, I shouldn't be surprised. But maybe it's time I introspect why this keeps happening to me, or do I need a couple more data points. 
Hi @mariusor,
json-ld has this whim to be completely indifferent about #cardinality.
@mro I'm not sure I understand what cardinality is when it comes to JSON-LD.
@mariusor "I'm used to coding this way" should be an acceptable answer.
You are more productive in your style. They are more productive in their style.
The relationship between familiarity and productiveness has been proven by research.
If you need to work on the same codebase, compromises help. One can even change their style.
@emilis yes, of course. I'm in their house, I try to follow their rules.
What I find difficult is to articulate why this way of doing what I'm doing is correct, because it relies on things which I find so basic that I usually can't do more than vaguely gesture to something like "simpler code is better"... :D
Install bonfire.cafe
Get the full app experience
