439 karma · joined June 4, 2012
Disarming in a sense that they will usually be inclined to react in a magnanimous way, instead of possibly adopting some other frictional communication pattern. It really just makes everything easier if you actively try to leave your ego at the door.
If we survive for long enough as a species, either we'll meet races in this manner or we'll be the ones doing it.
For the record I still only assign a fairly low probability that this is what is happening, it's more likely that UAPs are craft from terrestrial origin.
For the record, I don't believe we're close to AGI but I'm also pretty far from knowing anything about that field.
So should everyone be forced to value all future human lives as being as concretely valuable as our own? In order to put them into a total ordering of morality one is forced to make a judgement call on how many people we think are likely to exist in the future as well as how relevant our musings of today actually capture what life will be like in that future.
Effective altruists like to use exponential growth to beat people over the head with the idea that the future is more important than the present. Do they ever acknowledge the fact that the far future is also exponentially more unpredictable than seconds into the future?
It just reeks of hubris to me. To be a really effective altruist you must first create a time travel device.
Monorepo can be much easier as you can at least verify the given build is consistent.
Monoliths don't completely avoid the problem of version compatibility, they just reduce it to a more clear layer of external clients and compatibility between N-1th release and Nth release. That's certainly worth it in the early stages of a project
I always thought it was more common for stuff like KV stores with looser guarantees
Not to suggest he's operating in any way like a non-profit, but they all receive money and then distribute that money in ways that either increase the future money they can use for their mission or directly on the mission itself. The fact that he's built a self-sustaining model for helping individuals without merely forking over his own assets is impressive.
That being said I agree with you that interfaces for literally everything is a bad idea. Especially depending on interfaces everywhere, given that it's often quite nice to know concretely what some piece of code is trying to do.
The original post isnt super clear to me regarding how often the author actually recommends using interfaces. The examples used are for storage backends in projects like Kubernetes, which most people would probably agree is a pretty good context in which to utilize interfaces.
Not to mention inflation and low unemployment numbers. even if what you're saying is true, how could it stay that way for longer than a year or so
1. Reduce the total number of HTTP connections required to get the data for a specific component or page. Imo this is presumably less important with http3 but the driving force is probably similar for both.
2. Give backend-for-frontend style services more autonomy to provide an interface that works for a specific feature on the front end without coupling it to specifics of how the backend organizes resources
3. Allow performance issues with frontend query logic to be addressed without changing anything on the front end
I think the situations where it would be useful are large teams that want to operate more independently where the overhead of dealing with graphql is worth it.
An example being someone trying to render a component for a list of comments. It would be great if the front end could just write some "magic" query that gives them everything they want and they don't have to worry about batching requests to specific endpoints and the order in which they should make those requests. That doesn't mean the problem magically goes away, but it's now someone else's problem and that's good: the app development can free itself from things it shouldn't care about.
1. write ahead log before you do side effects/idempotent side effects
2. double writes to disk to prevent torn writes
3. checksums to make sure we don't make bad decisions based on bad data
4. redundancy/anti-entropy/other distributed system patterns which attempt to obviate the need to be overly concerned with a single process crashing
5. self-healing patterns when bad data is found
anyone have any other ideas?