Differential: Type safe RPC that feels like local functions

Idempotency & Delivery Semantics

• Large part of the thread debates the “idempotency” feature.
• Critics argue the framework cannot make arbitrary effectful functions truly idempotent; at best it can offer at-most-once or at-least-once semantics, not exactly-once.
• The system reportedly uses idempotency keys plus a lock/lease; for functions marked idempotent it aims for at‑most‑once by only issuing the call once to a worker. If not marked, failed calls may be retried on another machine (at‑least‑once).
• Several commenters say the docs and marketing blur these distinctions and risk misleading users, especially when examples involve payments.
• Some suggest renaming the feature to something like “tryOnce” or “retry policy” instead of “idempotency.”

Error Handling, Retries & AI

• Errors are surfaced as exceptions in async functions; timeouts from lost replies are treated similarly.
• There is an AI-based “predictive retries” feature that classifies errors (e.g., connection resets, deadlocks) as transient and retries automatically.
• This is opt‑in and currently a global (per-cluster) switch; some argue it should be per-function and question the value of AI here versus explicit annotations.
• Concern: if the AI misclassifies a non-idempotent operation as retryable, side effects could be applied twice.

RPC Abstraction & Distributed Systems Concerns

• Many push back on the tagline “feels like local functions,” warning that hiding network realities (latency, partial failure, partitions) historically leads to fragile distributed monoliths.
• Others say RPC-like ergonomics are fine as long as developers remain aware they’re in “distributed systems land.”
• There is broader debate about whether making remote calls feel easy encourages bad architectures versus empowering teams who have already chosen microservices.

Architecture, Scope & Serialization

• Product is described as type-safe RPC for backend/microservices with a centralized control-plane orchestrating calls, retries, and health checks (clustered for availability).
• Some see it as “trpc/rspc + service mesh”; others call it “service mesh with bells & whistles.”
• It’s TypeScript-first, which raises concerns for polyglot environments versus IDL-based systems like gRPC.
• Arguments must currently be JSON-serializable; functions/promises aren’t supported yet. Critics say this omits the harder parts of building a true distributed language runtime (closures, aliasing, mutation semantics).

Reception & Maturity

• Several commenters find the idea interesting and note similar internal systems in big companies.
• Many criticize unclear or overreaching docs/marketing, especially around idempotency and reliability guarantees, but acknowledge the project is early and still iterating.