Magnolia9438
This is fine for a lot of general purpose code that exits when running into problems. But when errors are an expected part of a long lived process, like an API, it’s painful to build logic around and conditionally handle them.
The ergonomics of errors.Is and As are pretty bad and there doesn’t seem to be a clear indication as when to expect a sentinel, concrete, or pointer to a concrete error.
All that to say, I think Go’s errors really illustrate the benefit of “return values, not interfaces”. Though for errors specifically, I’m not sure you could improve them without some pretty bad tradeoffs around flexibility.
Startup a dev server on the remote machine and forward the port to localhost. It should now be accessible via http://localhost:[port] on your local machine in the browser or any application, as if it’s running locally.
I find it’s very useful for also for interacting with DBs/Redis. Just forward the port your DB communicates on and use whatever client on your local machine to interact with it.
As far as I know this works with any service that communicates via TCP
I think we could all reasonably agree that 0% transparency would be never acknowledging any change at all and 100% would be a disclaimer message on every instance a blue checkmark is shown.
If we split that down the middle, which seems fair, a page shown on next login that explains the differences and has the user click an acknowledgment button is where I see the midpoint to transparency is.
A press release doesn't meet that bar for me. If you use the service there should be an attempt to inform you an important change has been made to the platform, before continuing. And not in some legalise policy document nobody reads. This is where we really need those flashy corporate landing pages with info-graphics that make it easy for everyone to grok the changes.
Anything less seems deceptive to me. If you aren't trying to deceive, catch your users at the door. They can decide from there.