On the happy path downstream, yes, and it does work really well. But the error flow back upstream flips that, as errors are returned as, often nested, interfaces.
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.
Maybe I’m misunderstanding, but I think what you want already exists as VSCodes remote SSH tunnel port forwarding (not the one that makes it publicly accessible).
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
Yeah, it would help with using the tool to access a private-to-the-remote API.
Won't immediately help with giving that tool access to the file system or Git.
For a local VM, you can have file system mounts, fast enough for Git.
SSHFS could help in some genuinely distant remotes with access to the file system (though SSHFS in the context of multiple file writers is fraught with risk of file corruption; been there, bought that T-shirt).
With properly network-remote VMs, nothing helps that much with giving the tool access to performing Git operations on changes inside your remote: Git is slow over network file systems even when they are quite local.
This is the real power of the VS Code remote after all; everything happens there.
Does "front page news" and "publicly announced" really constitute a reasonable disclosure to the users? I am not even sure what "front page news" actually means anymore? I so frequently get a different set of must-share news from various people that I have to wonder how much overlap most of our lives really have.
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.
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.