Differential: स्थानीय फ़ंक्शनों जैसा महसूस होने वाला टाइप-सेफ RPC

Idempotency & Delivery Semantics

• थ्रेड का बड़ा हिस्सा “idempotency” फीचर पर बहस करता है।
• आलोचकों का तर्क है कि फ्रेमवर्क मनमाने effectful functions को सचमुच idempotent नहीं बना सकता; अधिकतम यह at-most-once या at-least-once semantics दे सकता है, exactly-once नहीं।
• रिपोर्ट के अनुसार सिस्टम idempotency keys के साथ एक lock/lease का उपयोग करता है; idempotent चिह्नित functions के लिए इसका लक्ष्य at‑most‑once होता है, यानी कॉल केवल एक बार worker को भेजा जाता है। यदि चिह्नित नहीं है, तो विफल कॉल किसी दूसरे machine पर retry हो सकते हैं (at‑least‑once)।
• कई टिप्पणीकार कहते हैं कि docs और marketing इन भेदों को धुंधला करते हैं और उपयोगकर्ताओं को गुमराह करने का जोखिम पैदा करते हैं, खासकर जब उदाहरणों में payments शामिल हों।
• कुछ लोग फीचर का नाम “idempotency” के बजाय “tryOnce” या “retry policy” जैसा कुछ रखने का सुझाव देते हैं।

Error Handling, Retries & AI

• errors को async functions में exceptions के रूप में surface किया जाता है; खोए हुए replies से आने वाले timeouts को भी इसी तरह माना जाता है।
• एक AI-आधारित “predictive retries” फीचर है जो errors (जैसे connection resets, deadlocks) को transient मानकर स्वचालित रूप से retry करता है।
• यह opt‑in है और वर्तमान में एक global (per-cluster) switch है; कुछ लोगों का तर्क है कि यह per-function होना चाहिए और यहाँ AI के बजाय explicit annotations की उपयोगिता पर सवाल उठाते हैं।
• चिंता: यदि AI किसी non-idempotent operation को retryable मानकर गलत वर्गीकृत कर दे, तो side effects दो बार लागू हो सकते हैं।

RPC Abstraction & Distributed Systems Concerns

• कई लोग “feels like local functions” tagline का विरोध करते हैं, चेतावनी देते हैं कि network realities (latency, partial failure, partitions) को छिपाना ऐतिहासिक रूप से fragile distributed monoliths की ओर ले जाता है।
• अन्य लोग कहते हैं कि RPC-like ergonomics ठीक हैं, बशर्ते developers को यह पता रहे कि वे “distributed systems land” में हैं।
• इस बात पर व्यापक बहस है कि remote calls को आसान महसूस कराना खराब architectures को बढ़ावा देता है या उन teams को सक्षम करता है जिन्होंने पहले ही microservices चुनी हैं।

Architecture, Scope & Serialization

• उत्पाद को backend/microservices के लिए type-safe RPC के रूप में वर्णित किया गया है, जिसमें एक centralized control-plane calls, retries, और health checks orchestrate करता है (availability के लिए clustered)।
• कुछ लोग इसे “trpc/rspc + service mesh” मानते हैं; अन्य इसे “service mesh with bells & whistles” कहते हैं।
• यह TypeScript-first है, जिससे polyglot environments बनाम gRPC जैसे IDL-based systems को लेकर चिंताएँ उठती हैं।
• arguments वर्तमान में JSON-serializable होने चाहिए; functions/promises अभी समर्थित नहीं हैं। आलोचकों का कहना है कि यह एक true distributed language runtime बनाने के कठिन हिस्सों (closures, aliasing, mutation semantics) को छोड़ देता है।

Reception & Maturity

• कई टिप्पणीकार विचार को दिलचस्प मानते हैं और बड़ी कंपनियों में इसी तरह के internal systems का उल्लेख करते हैं।
• बहुत से लोग अस्पष्ट या जरूरत से ज्यादा दावे करने वाली docs/marketing की आलोचना करते हैं, खासकर idempotency और reliability guarantees के आसपास, लेकिन यह भी स्वीकार करते हैं कि project शुरुआती चरण में है और अभी भी विकसित हो रहा है।