LLM द्वारा TypeScript compiler, checker और lsp को Rust में पोर्ट करना

मूल लेख ↗ Hacker News चर्चा ↗

LLM-चालित TypeScript compiler और type checker के Rust ports लागत, performance, और maintainability पर सवाल उठा रहे हैं। Commenters “$400k of API tokens” वाले headline दावे पर बहस कर रहे हैं (जो largely subscriptions के जरिए subsidized था), इस काम पर OpenAI और Anthropic models की प्रभावशीलता की तुलना कर रहे हैं, और खासकर WebAssembly target करते समय compilers के लिए Rust बनाम Go और JavaScript पर विचार कर रहे हैं। कई लोग इस project को एक striking proof-of-concept मानते हैं—official toolchain से तेज़ लेकिन संभवतः unmaintained—और एक ऐसे भविष्य की शुरुआती झलक के रूप में देखते हैं जहाँ बड़े, जटिल systems नियमित रूप से languages के बीच machine-translate किए जाते हैं।

प्रोजेक्ट लागत और LLM अर्थशास्त्र

  • README में दिए गए “$400k in API-priced tokens” ने व्यापक बहस छेड़ दी।
  • कई टिप्पणियाँ बताती हैं कि यह एक सैद्धांतिक API-समतुल्य लागत है; व्यवहार में यह subscriptions और evaluation credits के जरिए किया गया, और वास्तविक खर्च लगभग ~$24k बताया गया, तथा अंतिम सफल पास के लिए संभवतः इससे भी कम।
  • कुछ लोग मानते हैं कि API-समतुल्य लागत बताना भ्रामक “flexing” है; दूसरे कहते हैं कि यह उपयोगी है ताकि पता चले कि यह काम list prices पर कितना महंगा पड़ता।
  • AI कंपनियाँ भारी subscription उपयोगकर्ताओं पर “पैसा खोती” हैं या नहीं, इस पर भी चर्चा है; कुछ लोग reported high gross margins का हवाला देते हैं और तर्क करते हैं कि subscriptions कम-से-कम break-even हैं।

Rust बनाम Go बनाम JS और WASM

  • कई टिप्पणियाँ नोट करती हैं कि यह मूल TypeScript compiler के Go rewrite का एक Rust port है।
  • Go बनाम Rust पर बहस: Go को ergonomics और आसान porting के लिए चुना गया था; Rust को performance और WebAssembly के लिए बेहतर माना जा रहा है (छोटे, तेज binaries, minimal runtime)।
  • अन्य लोग कहते हैं कि Go भी WASM को target कर सकता है (खासकर TinyGo) और GC बनाम non-GC को “तेज़/धीमा” कहकर सरल नहीं किया जा सकता।
  • कुछ तर्क देते हैं कि JS को कभी भी नए implementation language के रूप में गंभीरता से नहीं सोचा गया, और यह एक missed opportunity थी; दूसरे बताते हैं कि TS मूल रूप से JS में ही था।

LLMs as Coders: गुणवत्ता, परीक्षण, और भरोसा

  • यह port काफी हद तक LLMs द्वारा बनाया गया था, और एक model (Opus) ने गति और प्रगति में पहले के OpenAI प्रयासों से काफी बेहतर प्रदर्शन किया।
  • लेखक कहते हैं कि उन्होंने “never read a line of this code,” जिसे कुछ commenters गैर-जिम्मेदाराना मानते हैं; दूसरे मानते हैं कि पूरा TS test suite पास करना पर्याप्त है।
  • चिंताएँ उठाई गईं: ऐसे hidden gaps जहाँ मूल tests “common sense” पर निर्भर थे; उस code की maintainability जिसे कोई human समझता नहीं; बदलती आवश्यकताओं के साथ लंबी अवधि का विकास।
  • प्रतिवाद: बहुत अधिक tested systems में, tests के खिलाफ iterate करने वाले agents मनुष्यों की तुलना में कम gaps छोड़ सकते हैं, और भविष्य के workflows में manually code edit करने के बजाय tests जोड़ना केंद्र में हो सकता है।

गंभीरता, प्रभाव, और भावनात्मक प्रतिक्रियाएँ

  • कुछ लोग इस project को एक meme/experiment मानते हैं, जिसके maintain होने की संभावना कम है, “running Doom on a microwave” जैसा, लेकिन फिर भी capability demo के रूप में महत्वपूर्ण।
  • अन्य लोग वास्तविक उपयोगिता पर जोर देते हैं: कुछ real-world projects में tsc की तुलना में 1.6–4x speedups की रिपोर्ट, और WASM deployments के लिए बेहतर उपयुक्तता।
  • भावनात्मक विभाजन: कुछ लोगों को लगता है कि AI rewrites “craft” को हटा देते हैं और ऐसे projects कम प्रेरणादायक बनाते हैं; दूसरे इस पर ध्यान देते हैं कि development cost बहुत घटने से व्यावहारिक रूप से क्या-क्या संभव हो जाता है, उसका विस्फोट।