7 वर्षों के प्रोडक्शन के बाद, Scarf अनिच्छा से Haskell से दूर हो गया है

LLMs के साथ Types की भूमिका

• कई लोग तर्क देते हैं कि LLMs के साथ मजबूत static types और अधिक मूल्यवान हैं, क्योंकि ये “junk” आउटपुट को पकड़ते हैं और AI‑generated code को समझना तथा refactor करना आसान बनाते हैं।
• अन्य लोग बताते हैं कि LLMs अक्सर खुद ही सरल गलतियों से बच जाते हैं या उन्हें जल्दी ठीक कर देते हैं, इसलिए बहुत मजबूत type systems का marginal लाभ पहले की तुलना में कम हो सकता है।
• इस बात पर असहमति है कि LLMs type safety की आवश्यकता को कम करते हैं या उसे और अधिक महत्वपूर्ण बनाते हैं; कई टिप्पणीकार “कम type safety” वाले निष्कर्ष को स्पष्ट रूप से हैरान करने वाला मानते हैं।

Compile Times और Agent Workflows

• मुख्य शिकायत: Haskell के धीमे cold compile times agentic workflows के लिए एक गंभीर bottleneck बन जाते हैं, जिनमें बार-बार build और test चलाए जाते हैं, खासकर कई worktrees/agents में।
• कुछ लोग कहते हैं कि कम, लेकिन अधिक समृद्ध compiler checks धीमी compiles की भरपाई कर सकते हैं, लेकिन मानते हैं कि 15‑मिनट की base cost को amortize करना कठिन है।
• कई लोग नोट करते हैं कि यह समस्या पहले से ही human productivity को नुकसान पहुँचा रही थी; LLMs ने बस इसे अधिक दिखाई देने योग्य बना दिया है। अन्य लोग rewriting के बजाय बेहतर build caching/infra का सुझाव देते हैं।

Python बनाम अन्य Language Choices

• कई लोग हैरान हैं कि यह move TypeScript, Go, OCaml, Rust, Java, C#, F#, आदि के बजाय Python की ओर है, जो decent compile times के साथ बेहतर typing देते हैं।
• Python के पक्ष में दलीलें: team familiarity, बड़ा ecosystem, models के लिए abundant training data, और कोई compile step नहीं।
• आलोचनाएँ: कमजोर और fragmented typing ecosystem, कई type tools की आवश्यकता, libraries में inconsistent annotations, servers के लिए अनेक “footguns”, और खराब runtime performance।

Haskell और Alternatives के साथ अनुभव

• कुछ लोग बहुत productive Haskell+LLM workflows की रिपोर्ट करते हैं और व्यवहार में compile time को कोई बड़ा मुद्दा नहीं मानते।
• अन्य लोग पहले ही Haskell छोड़ चुके हैं (जैसे Rust के लिए) क्योंकि laziness, exceptions, ecosystem size/fragmentation, और tooling pain जैसी समस्याएँ थीं।
• OCaml, Lean, F#, Go, और JVM languages को बार-बार promising middle grounds के रूप में उद्धृत किया जाता है: तेज compiles के साथ उपयोगी types।

AI-युग पर व्यापक विचार

• इस पर बहस है कि क्या हम एक “post-language” दुनिया की ओर बढ़ रहे हैं, जहाँ agents efficiency (runtime, token cost, wall-clock) के आधार पर language choice को संचालित करते हैं।
• चिंता है कि “vibecoding” speed के लिए optimization engineering rigor और long-term maintainability को कमजोर कर सकता है।
• कुछ लोग तर्क देते हैं कि भविष्य की languages को चुनाव करना होगा: मुख्यतः humans के लिए design की जाएँ या agents के लिए; ये लक्ष्य एक-दूसरे से टकरा सकते हैं।