Ask HN: Feedback on a new framework aiming at the classic RPC headaches

TL;DR: Built an RPC framework that uses various approaches to solve existing RPC issues. Docs-only preview, seeking feedback before finalizing.

After seeing the same complaints about RPCs resurface for years, I spent the last year building a new RPC framework, AtomicLinkRPC (ALR).

The same article spawns heated discussions every few years:

https://reasonablypolymorphic.com/blog/protos-are-wrong/

And then the discussions based on that:

https://news.ycombinator.com/item?id=21871514

https://news.ycombinator.com/item?id=35281561

https://news.ycombinator.com/item?id=45139656

I've implemented a concrete, end-to-end answer to these issues and have published a docs-only preview (C++ first):

https://atomiclinkrpc.github.io/alr-preview/

Brief example:

  // service.h
  class Greeter : public alr::EndpointClass
  {
  public:
      static std::string sayHello(const std::string& name);
  };

  // service.cpp
  std::string Greeter::sayHello(const std::string& name)
  {
      return "Hello " + name;
  }

  int main()
  {
      return alr::ConnectionInfo()
          .setListenAddress("0.0.0.0:55100")
          .listen();
  }

  // client.cpp
  #include "alr/endpoint.h"
  #include "client_gen.h"

  int main()
  {
      alr::Endpoint ep = alr::ConnectionInfo()
          .setConnectAddress("service-host:55100")
          .connect();
  
      auto result = Greeter::sayHello("World"); // Happens to be RPC
  
      printf("%s\n", result.c_str());
      return 0;
  }

Below is a short list of issues brought up by the above discussions, and a brief description of how ALR solves each. I'd love your critique on what you think about these approaches, where you believe they'll break, and what's missing (but see the docs link for more in-depth details).

1) Impedance mismatch: App code contorts to fit the transport

- In ALR, "messages" and other RPC specific concepts become low-level implementation details, never to be seen by your business logic. Remotable classes, methods and structs stay clean from RPC noise and map 1:1 to your business logic.

- ALR uses an ambient variable system (see the docs), which is a set of thread-local variables that together provide all the context needed to perform RPCs without dragging context variables throughout your business logic. Only your own clean classes, clean functions, clean structs, and native types. No noise.

2) API evolution is broken, fragile, inconsistent or difficult to use and maintain in reality.

- ALR directly uses your classes, methods and structs as the schema, with no fragile tags.

- ALR negotiates schemas and visitor layout mapping at handshake time and creates an intersection map to allow different versions to interoperate.

3) Steep learning curve to understand and implement RPC frameworks

- Besides deriving your remotable class from an ALR base class, there isn't much new API to learn.

- Please check out the examples in the docs-preview link to get a feel for how easy it is to use compared to other frameworks.

4) Performance

- Benchmark results show that ALR can significantly outperform gRPC, see the results in docs. I'll be happy to discuss how those results are even possible.

Questions for HN

1. Do you see any flaws with ALR's approach to solving some of these issues?

2. If you have counterexamples where the dynamic remote capability check falls down, I want to hear them.

3. What RPC pain points am I missing that aren't addressed by ALR?

4. Any specific areas that need more detail here or in the docs?

Status & scope

- This is a docs-only preview. I'm seeking adversarial feedback before I freeze the interfaces.

- The source is not public yet while I finalize the open-source license.

- C++ is the first supported language, with plans for Python, Rust, and others.

Thanks for taking a look - blunt feedback welcome!