Comments URL: https://news.ycombinator.com/item?id=39100469

Points: 2

# Comments: 0

However, now that I think again about the serialization format choice, it may result in a limitation on the size of monoliths (in terms of the number of people / teams contributing to it). When the number of contributors grow, the likelihood of bugs in a binary grows, and teams adopt more elaborate qualification processes, and also become much more sensitive to binary rollbacks as a remedy to discovering bugs in prod. Then they could institute policies like all changes should be protected by a feature flag (aka an experiment).

If non-versioned serialization format is used, that means that the platform cannot possibly rollback a single component. However, using versioned serialization won't be enough on its own to support per-component rollbacks — it at least requires independent component qualification (where each component is tested against "stable" versions of other components) + rollback testing to make rollbacks A2 -> B2 to A2 -> B1 safe.

I wonder if it's an explicit design choice — i.e., whether Service Weaver supports monoliths up to a certain organizational size (and then you should split into separate service weaver apps)?

The paper unfortunately hides that in reality you have to pass a context object in your RPC calls, hence there is no ambiguity whether you are calling a potentially remote object.

It's in the example on the project home page: https://serviceweaver.dev/

  // The "RPC" handler
  func (adder) Add(_ context.Context, x, y int) (int, error) {
      return x + y, nil
  }

  // The call-site
  var adder Adder = ... // See documentation
  sum, err := adder.Add(ctx, 1, 2)

> Java RMI use a programming model similar to ours but suffered from a number of technical and organizational issues [58] and don’t fully address C1-C5 either

Apart from that, it looks like Java RMI allowed remote objects returning other remote objects, rather than only immutable values. With that you could abuse it by making a call to one java.rmi.Remote object, getting another java.rmi.Remote object in response, then passing it around, and then finding a totally different subsystem suddenly make RPCs (however, such abuse probably would be easy to spot in a code review, as it requires a modification to the remote object interface).

---

The authors also acknowledge that it doesn’t solve the distributed computing challenges:

> our proposal does not solve fundamental challenges of distributed systems [53, 68, 76]. Application developers still need to be aware that components may fail or experience high latency

I think at least in terms of latencies their platform can occasionally inject latencies into some percentage of the tasks, then verifying if any alerts fire, if there is a fear the components become dependent on a certain deployment shape (within a cluster).

> The call to hello.Greet looks like a regular method call

That’s a departure from how components interact in boq — an internal and widely used production platform that has _some_ of the features from the paper. There component interfaces _are_ RPC interfaces (e.g., Stubby / gRPC + protocol buffers), and interaction between them is possible exclusively through the component interfaces. Hence it’s very explicit at the call site that an RPC is being made (which could happen to execute locally with all the standard RPC functionality — context and deadline propagation, etc.).

RPCs looking like regular method calls sound a bit scary (easy to miss in code reviews); I wonder if enforced naming conventions + IDE + code review tool support would be enough.

Edit: it seems to require to pass a context object, so the readers won't confuse it with a local call (from https://serviceweaver.dev/):

  sum, err := adder.Add(ctx, 1, 2)

Also, the paper claims that most benefits come from a non-versioned serialization format:

> Most of the performance benefits of our prototype come from its use of a custom serialization format designed for non-versioned data exchange [...]

However, I don’t understand why local RPC calls have to serialize protocol buffer messages — can’t they already pass them as-is to the local handler?

(disclaimer: a googler, no internal knowledge on ServiceWeaver)

My previous Xperia Compact, which is of about the same dimensions as mini, survived for a couple of days easily when new.

> iPhone Mini has been weak in battery department [1]

The article says "solid battery life", which matches my experience with 13 mini.

Not necessarily.

I bought an iPhone Mini expecting that it'd be comfortable to use in a single hand like my previous Xperia phone of exactly the same width.

Unfortunately, it is not the case: the iPhone screen is very close to the bottom edge, and to switch apps you need to move your thumb to the very edge and then swipe up, which is rather uncomfortable (or requires holding your phone very low, in which case, you can't reach the top of the screen without changing your grasp). Similarly, the keyboard is rather low and uncomfortable to use from the otherwise most natural single-handed grasp.

- https://openjdk.java.net/jeps/310 - https://openjdk.java.net/jeps/341 - https://openjdk.java.net/jeps/350

Edit: There is a help entry: https://semgrep.dev/docs/faq/#how-is-semgrep-different-from-...