Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> It's very rare to meet a developer who has even the vaguest notion of what an RPC call costs in terms of microseconds.

To be fair, small time units are difficult to internalize. Just look at what happens when someone finds out that it takes tens of nanoseconds to call a C function in Go (gc). They regularly conclude that it's completely unusable, and not just in a tight loop with an unfathomable number of calls, but even for a single call in their program that runs once per day. You can flat out tell another developer exactly how many microseconds the RPC is going to add and they still aren't apt to get it.

It is not rare to find developers who understand that RPC has a higher cost than a local function, though, and with enough understanding of that to know that there could be a problem if overused. Where they often fall down, however, is when the tools and frameworks try to hide the complexity by making RPC look like a local function. It then becomes easy to miss that there is additional overheard to consider. Make the complexity explicit and you won't find many developers oblivious to it.



>Just look at what happens when someone finds out that it takes tens of nanoseconds to call a C function in Go (gc).

I'm not too familiar with Go but my default assumption is that it's just used as a convenient excuse to avoid learning how to do FFI.


Those time cost need to contextualize with time budgets for each service. Without that, it is always somebody else's problem in a RPC world.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: