dullgiulio

> But it's not going to be Unix as we know it.

Right, that's Plan9.

No shortcuts.

Errors reach end users, and they cannot read stack traces.

Every shortcut makes for bad errors, bad troubleshooting and unhappy users.

Errors document code (you literally write, in English, what you were trying to do but failed, at each level of your program.)

Errors report to the user the clear intent that failed and why.

Errors are a huge differentiator in quality. There is no shortcut to quality.

Please no. I am still fighting the battle of adding contextual information to the error using fmt.Errorf.

I am tired of seeing

SocketException: hostname.com

as full error message.

Readable but not comprehensible. CSV is hard to beat in that sense, being somewhat "natural" like a table written on paper.

No, a normal light switch on the wall is all you need.

No, it failed because it acts on the wrong side. If you don't want to be tracked you shouldn't send cookies in your request.

This comment makes little sense. AWS is even less uniform when it comes to tools, exactly because of its organic growth. This clearly has no impact on its success nor its features.

Google does have a problem with management and the org-chart, but not the way you think.

Most probably all these names just indicate market day...

That's the Go runtime.

You have to implement UnmarshalJSON. Between each attempt to deserialize into a possible struct, be careful to return on errors that are not JSON serialisation errors (for example caused by reading from the underlying Reader, etc.)

It's ugly and verbose but there is no need to use empty interface.

No, that SIMD is good for string matching and Rust regex crate (written by burntsushi for 'ripgrep') makes very good use of it and is thus a nice library for implementing quick matchers.

And is Go so hard to upgrade for your application?

Go the language is really best in class when it comes to keeping backwards compatibility.

Redirection is not a parameter, meaning that would still not work with this Q tool.

Another reason for people trying too look overly confident is when they are overly exposed over a certain topic.

For example, if you have very narrow job titles and roles in a team ("he is our DevOps, she is our architect"...) everyone will have to defend their role, often trying to sound infallible.

If instead you make the whole team responsible for all team tasks, everyone will be more open to leveraging everyone else's suggestions.

Tangentially, the adage "strong opinions, weakly held" is nonsense. If you have a strong opinion, you look like a fool if you change your mind when evidence is shown to you.

It is much better to just stay humble. Show your insecurities and lack of knowledge openly and early, you'll be surprised to see how people reactions change from hostile/confrontational to outright helpful.