i think you would benefit from some time in an organization that was not shitty
797 karma · joined July 22, 2023
i know that lots of orgs don't do it this way, but it's really important to make this point very clear: those orgs are wrong, and pathological, no matter how many of them there are
git is a means, not an end
code review is about the code as a unit whole, not the steps along the way!
some people treat commits as meaningful units of independent review, and some people treat them as savepoints and the PR as the only meaningful unit of review, it's a distinction of process, not purity -- both approaches are totally fine, one is not better than the other
git and commits and prs are means, not ends
the point is not queue progression, it is about dissemination of knowledge
one holistic change to a project = one PR
simple stuff really
code review is meant to take time
commits mean precisely what their author intend them to mean, nothing more
if you squash-merge every PR then history is clean where it matters
RPC is an ambiguous and abstract umbrella-term for any request-response communication between two nodes that don't share the same memory space, usually over a network connection, and always via serialized bytes.
> Without RPC, you might communicate using a protocol like HTTP.
HTTP is probably the most common protocol for implementing RPC, indeed
> With HTTP, though, you must format and parse your communications as an HTTP request and response, perhaps designed in REST style.
yep! HTTP/REST is one good option, among many, for doing RPC communications
> RPC systems try to make communications look like a regular function call instead, as if you were calling a library rather than a remote service. The RPC system provides a "stub" object on the client side which stands in for the real server-side object.
Er, no, if you introduce the concept of "objects" you're now talking about something quite different than RPC, more akin to CORBA, which we well know now is not sound...
> When a method is called on the stub, the RPC system figures out how to serialize and transmit the parameters to the server, invoke the method on the server, and then transmit the return value back.
I mean, sure, but this is just normal serialization protocol stuff, right?
> The merits of RPC have been subject to a great deal of debate. RPC is often accused of committing many of the fallacies of distributed computing. But this reputation is outdated. When RPC was first invented some 40 years ago, async programming barely existed. We did not have Promises, much less async and await. Early RPC was synchronous: calls would block the calling thread waiting for a reply. At best, latency made the program slow. At worst, network failures would hang or crash the program. No wonder it was deemed "broken". Things are different today. We have Promise and async and await, and we can throw exceptions on network failures. We even understand how RPCs can be pipelined so that a chain of calls takes only one network round trip. Many large distributed systems you likely use every day are built on RPC. It works.
What a confusion of terms and concepts! Promises and async/await are language-level concepts, completely orthogonal to "RPC" which is a transport/wire-level concept -- what is happening here!! :o
> The fact is, RPC fits the programming model we're used to. Every programmer is trained to think in terms of APIs composed of function calls, not in terms of byte stream protocols nor even REST. Using RPC frees you from the need to constantly translate between mental models, allowing you to move faster.
i do not think RPC means what this author thinks that it means
RPC is "remote procedure call", emphasis on "remote", meaning you always necessarily gonna be serializing/deserializing the information over some kind of wire, between discrete/different nodes, with discrete/distinct address spaces
a client request by definition can't include anything that can't be serialized, serialization is the ground truth requirement for any kind of RPC...
a server doesn't provide "an object" in response to a query, it provides "a response payload", which is at most a snapshot of some state it had at the time of the request, it's not as if there is any expectation that this serialized state is gonna be consistent between nodes
i don't disagree with you but if "adding one more CRUD endpoint" and similar rote tasks represent any significant amount of your engineering hours, especially in the context of business impact, then something is fundamentally broken in your team, engineering org, or company overall
time spent typing code into an editor is usually, hopefully!, approximately statistically 0% of overall engineering time
i.e. until that "formal grammar" which is currently a comment in a Kotlin source file ;) becomes a versioned and reference-able spec that can be implemented by third-parties this is all a bit of a cart/horse dilemma i think maybe
but there isn't a single YAML spec, there are at least 2 in common use: yaml 1.1, and 1.2, which have discrete specs and feature-sets. re: anchor stuff specifically, 1.1 supports merge keys whereas 1.2 explicitly does not, so that's one thing
and github actions does not actually specify which yaml spec/version it uses when parsing workflow yaml files
it's unfortunately just not the case that "YAML means something" that is well-defined in the sense that you mean here
if the act of writing code is something you consider a burden rather than a joy then my friend you are in the wrong profession
yes
> If so, how would it allocate that buffer?
as it sees fit. or, it can offer mechanisms for the caller to provide pre-allocated buffer(s). in any case the point is that this detail can't be the responsibility of the producer to satisfy, unless that requirement is specified somehow explicitly
in general the new zig io interfaces conflate behavior (read/write) with implementation (buffer size(s))
name: 'Leonardo Bonacci'
favorite_books:
- title: Metaphysics
author: Aristotle.
favorite_numbers:
- 1
- 2
Forwards-compatible means the old thing can handle the new things. Here JSON is not forwards-compatible with JSON5.