Swift अपनाना बंद — Ladybird ब्राउज़र में Swift 6.0 सपोर्ट इश्यू बंद

(github.com/LadybirdBrowser)

1 पॉइंट द्वारा GN⁺ 2026-02-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Ladybird ब्राउज़र प्रोजेक्ट ने Swift 6.0 सपोर्ट को प्रयोगात्मक चरण से औपचारिक रूप से अपनाने की प्रक्रिया में सामने आए मुद्दों की सूची तैयार की थी, लेकिन बाद में Swift अपनाने को आगे न बढ़ाने का फैसला किया
मुख्य बाधाएँ Swift और C++ interoperability (Interop) से जुड़ी ABI असंगतियाँ, header circular dependency, कुछ types को return न कर पाना जैसी थीं, और इनमें से कई मुद्दे Swift 6.0.0 के बाद ठीक किए गए
CMake build system में भी Swift + Ninja वातावरण में deployment target mismatch, install_name हैंडलिंग त्रुटि, incompatible compiler options जैसी समस्याएँ रिपोर्ट हुईं
Ladybird के अपने कोड में भी AK और LibGfx modules के modulemap configuration, Swift frontend crash, type namespace conflict सहित कई build instability पाई गईं
इन जमा हुई तकनीकी सीमाओं के कारण Swift integration रोक दी गई, और इसका परिणाम C++-केंद्रित development बनाए रखने के निर्णय के रूप में निकला

Swift से जुड़ी समस्याएँ

Swift 6.0 सपोर्ट को प्रयोगात्मक चरण से बाहर लाने के लिए हल किए जाने वाले language और ABI स्तर के bugs बड़ी संख्या में मौजूद थे
- LLVM version mismatch के कारण Swift open source build के समय assertion failure होता था
- Optional<CxxValueType> return करने पर compiler और bridging header के बीच ABI mismatch समस्या
- Ubuntu 22.04 वातावरण में <execution> header शामिल करने पर libstdc++ module circular dependency होती थी
- swift::Optional<swift::String> return न कर पाना, <chrono> header लोड न होना जैसी C++23 compatibility समस्याएँ भी शामिल थीं
कुछ समस्याएँ Swift 6.0.0 के बाद की releases में ठीक हुईं, लेकिन कुछ केवल main branch में ही हल हुईं और stable version में शामिल नहीं हुईं
कई मदों में “workaround (वैकल्पिक build तरीका)” सुझाया गया, लेकिन यह पूर्ण समाधान नहीं था

CMake से जुड़ी समस्याएँ

Swift और Ninja build संयोजन में CMAKE_OSX_DEPLOYMENT_TARGET लागू न होने से कई warnings आती थीं
- CMAKE_Swift_COMPILER_TARGET को manually सेट करना पड़ता था
CMP0157 policy सक्षम होने पर install_name directory setting अनदेखी हो जाती थी, इसलिए manual correction की ज़रूरत पड़ती थी
- संबंधित fix को CMake 3.29, 3.30 में backport करने की योजना थी
Swift compiler जिन link options को समझ नहीं पाता, वे external dependencies से pass होने की समस्या भी मौजूद थी

Ladybird प्रोजेक्ट के अंदरूनी मुद्दे

AK और LibGfx modules के clang module map configuration के दौरान system headers से conflict होता था
- <math.h> शामिल करने पर module recognition error के कारण build fail हो जाता था
Swift frontend AK container tests के दौरान debug build में crash हो जाता था
- केवल release mode build से ही इससे बचा जा सकता था
String type namespace conflict के कारण Swift frontend असामान्य रूप से बंद हो जाता था
- AK.String या Swift.String के रूप में explicitly निर्दिष्ट करना पड़ता था
Swift Testing module इस्तेमाल करने पर compiler frontend crash होता था, और AK::StringView के लिए CxxSequenceType को न पहचानने की समस्या भी थी

अतिरिक्त सुधार बिंदु

Swift में जब C++ function Optional<CxxType> return करता था, तो application crash हो जाता था
- अस्थायी समाधान के रूप में size 0 या 1 के array return करने का उपयोग किया गया
SourceKit-LSP और vscode-swift को root स्तर पर compile_commands.json चाहिए होता था
- symbolic link बनाकर इसे हल किया जा सकता था
Linux वातावरण में <swift/bridging> path को manually जोड़ना पड़ने की असुविधा भी थी

अनसुलझे प्रश्न

Swift में C++ के view type या byte slice को बिना copy किए पास करने का तरीका स्पष्ट नहीं था
Swift AK::Optional, AK::HashMap जैसे अपने types को std:: types के बराबर नहीं पहचान पाता था
Swift garbage collector और Ladybird की memory management को integrate करने का तरीका भी तय नहीं था

यह इश्यू Swift 6.0 integration के लिए तकनीकी बाधाओं को व्यवस्थित रूप से दर्ज करने वाला दस्तावेज़ था, लेकिन बाद में Ladybird टीम ने Swift अपनाना बंद कर दिया, और “Swift 6.0 Blockers” इश्यू बंद कर दिया गया।

1 टिप्पणियां

GN⁺ 2026-02-20

Hacker News की रायें

Swift हटाने वाले commit में थोड़ा अतिरिक्त स्पष्टीकरण है
इसमें यह संदेश शामिल है: “काफ़ी समय से कोई प्रगति नहीं हुई, इसलिए Swift अपनाने का प्रयास छोड़कर इसे codebase से हटा दिया गया”
संबंधित commit यहाँ देखा जा सकता है
- इसका और विस्तृत संदर्भ issue #933 में संकलित है
मैंने 2021 में पहली बार Swift इस्तेमाल किया था, और 10 साल से ज़्यादा C#/.NET करने के बाद आकर मैं हैरान रह गया
मुझे C# भी जटिल लगता था, लेकिन Swift उससे कहीं ज़्यादा जटिल भाषा निकली
ख़ासकर backend API या data access layer बनाते समय देखने लायक सामग्री लगभग नहीं थी
Swift का ज़्यादातर ज्ञान Apple platforms के लिए जमा हुआ है, इसलिए उसके बाहर के क्षेत्रों में लगता था जैसे आपको लगभग पायनियर बनना पड़ेगा
- पिछले कुछ सालों में Python या Go जैसी सरल भाषाओं ने “जटिलता बुरी है” वाले तर्क को मज़बूत किया है, लेकिन मेरा मानना है कि भाषा की expressiveness ज़्यादा हो तो maintainability में मदद मिल सकती है
  जैसा Larry Wall ने कहा था, tool की complexity समस्या की complexity के मुताबिक होनी चाहिए (Raku का उल्लेख)
- मैं करीब 2018 में Objective-C से Swift पर गया था, और शुरुआत में यह सुधार जैसा लगा
  लेकिन “struct value से pass होता है, class reference से pass होती है” जैसे नियम और “single source of truth बनाए रखना” वाला सिद्धांत आपस में टकराते रहे, जिससे development उबाऊ और धीमा हो गया
  Swift की विरोधाभासी best practices की वजह से कोई प्रगति नहीं हुई, और आख़िर में समझ आया कि बहुत-सी सलाहों पर भरोसा नहीं किया जा सकता
- M1 MacBook पर Vapor template compile करते समय हर बार laptop बहुत गरम हो जाता था
- मेरा अनुभव भी ऐसा ही था. लगा था Rust की तरह जल्दी सीख लूँगा, लेकिन बिल्कुल नहीं
  syntax sugar बहुत ज़्यादा है, और एक ही काम करने के दर्जनों तरीके हैं, इसलिए हर बार language reference देखनी पड़ती थी
- इसलिए आख़िरकार क्या आप फिर से C#/.NET पर लौट गए, यह जानने की जिज्ञासा है
भाषा कोई भी हो, उम्मीद है कि Ladybird आगे चलकर user-friendly JavaScript implementation पर ध्यान दे
JS का user activity tracking, paste block करना, या device की ज़रूरत से ज़्यादा जानकारी इकट्ठा करने में दुरुपयोग होना एक समस्या है
Tor की तरह अगर users के बीच standardized spoofed values report किए जाएँ, तो privacy protection में मदद मिल सकती है
- लेकिन इस तरह का तरीका कई websites पर bot detection समझ लिया जा सकता है और access block हो सकता है
  toggle option के रूप में देना ठीक है, लेकिन default के रूप में रखना शायद adoption के लिए मुश्किल होगा
- जो browser web standards को नज़रअंदाज़ करके अपने तरीके से चले, मैं व्यक्तिगत रूप से ऐसा browser कभी इस्तेमाल नहीं करना चाहूँगा
Swift हटाना दिलचस्प है. वजह साफ़ तौर पर नहीं बताई गई, इसलिए जिज्ञासा है
अगर यह Linux पर चलने लगे तो मैं बाद में इसे test करने का सोच रहा हूँ
- मेरी नज़र में बार-बार build conflicts होने की वजह से इसे छोड़ा गया लगता है
  समस्या यह थी कि Swift एक साथ कई C++ version libraries import नहीं कर पा रहा था, या operator version conflicts हो रहे थे
  Swift अच्छी भाषा है, लेकिन पहले से बड़े project में बाद में जोड़ने के लिए शायद यह बहुत जटिल थी
जिज्ञासा है कि Ladybird ने Swift क्यों आज़माया. मुझे लगा था कि Rust की C++ interoperability बेहतर नहीं है क्या
Swift का GC भी browser performance के लिए नुक़सानदेह लग सकता है
- Andreas Kling ने Twitter पर कहा था कि “Swift vs Rust में Swift object-oriented support और C++ integration के मामले में बेहतर है”
  लिंक1, लिंक2
- यह कुछ वैसा ही है जैसे Rust game development में असुविधाजनक लगता है. borrow checker circular reference structures के साथ अच्छी तरह फिट नहीं बैठता
  workaround हैं, लेकिन productivity गिरती है
- Swift में वास्तव में interoperability काफ़ी अच्छी है, जैसा C++ interop documentation में भी दिखता है
  हालांकि Ladybird के लिए शायद यह काफ़ी नहीं था
- Andreas Kling ने यह भी कहा था कि Rust में object-oriented features की कमी है, इसलिए GUI development में यह कम अनुकूल है
  पहले SerenityOS में उन्होंने Jakt नाम की भाषा भी बनाई थी, लेकिन लगता है कि अंततः वे फिर C++ पर लौट आए
- मुझे याद है कि Rust को DOM hierarchy या OOP समस्याओं के कारण ख़ारिज किया गया था
  इस बारे में पुरानी चर्चा इस पोस्ट में है
Swift, Apple पर बहुत निर्भर भाषा है, इसलिए यह चौंकाने वाली बात नहीं है
C++ के सुरक्षित हिस्सों का ठीक से इस्तेमाल कर लिया जाए तो वह काफ़ी है, और वास्तव में ज़्यादातर browsers C++ में ही लिखे गए हैं
- लेकिन सभी browsers बस C++ में फँसे हुए हैं
  Chromium और Firefox धीरे-धीरे अधिक सुरक्षित भाषाओं से हिस्से बदल रहे हैं, और नए browser को फिर से C++ में लिखना अतीत की गलती दोहराने जैसा है
  C++ का उपयोग 1998 के KHTML दौर की विरासत है
- “modern memory-safe C++ subset” से आपका ठीक-ठीक क्या मतलब है, यह स्पष्ट नहीं है
  क्या इसमें string_view जैसी आधुनिक STL features शामिल हैं? फिर भी यह पूरी memory safety से काफ़ी दूर है
- मेरी जानकारी में Rust, Mozilla ने विकसित किया था; क्या Mozilla ख़ुद Rust में लिखा गया है, यह जिज्ञासा है
- जो भी हो, high-performance की ज़रूरत वाले क्षेत्रों में Swift के लिए C++ को हराना मुश्किल है
  कुछ benchmarks को छोड़ दें तो वास्तविक programs में यह लगभग हमेशा धीमी होती है
Swift हटना अफ़सोसजनक है. तो क्या उनकी अपनी भाषा Jakt फिर से उम्मीदवार बन सकती है, यह सोच रहा हूँ
- Ladybird पहले ही SerenityOS से अलग हो चुका है, और Jakt उनकी भाषा नहीं है
  मुझे नहीं लगता कि वे किसी नई भाषा को अपनाने की संभावना रखते हैं
- व्यक्तिगत रूप से मुझे चिंता है कि project बहुत बार दिशा बदलता रहता है
  बाहरी sponsorship पर चलने वाला project अगर ऐसा करे, तो लंबे समय तक टिकना कठिन हो सकता है
- समझ नहीं आता कि Rust क्यों नहीं. क्या यह C++ से लगाव की वजह है, ऐसा लगता है
मुझे लगता है Swift आख़िरकार सिर्फ़ Apple की खिलौना भाषा भर है
Apple उसे उससे आगे बढ़ने नहीं देगा
Ladybird का Mac UI, AppKit के ऊपर रखी गई एक पतली layer है
यह Swift में नहीं बल्कि Objective-C++ में लिखा गया है
source code देखें
- वह code शुरू में लिखने वाला मैं ही था
  यह Swift अपनाने से बहुत पहले, SerenityOS के समय बनाया गया था, इसलिए Objective-C++ इस्तेमाल करने की वजह बस यह थी कि वही परिचित भाषा थी
जब पहले Swift पर जाने की बात हुई थी, तब मैंने इसकी आलोचना की थी
मेरा मानना था कि Swift का design ढीला-ढाला है, compile speed भी धीमी है, और इसके system language के रूप में बढ़ने की संभावना कम है
experts भी नहीं थे, इसलिए मुझे लगता है यह फ़ैसला सही रहा
- Swift दिखने में open source है, लेकिन वास्तव में Apple के हाथ में ही सारी निर्णय-शक्ति है
  Concurrency या Swift Testing जैसी सुविधाएँ भी Apple की ज़रूरतों के मुताबिक आगे बढ़ाई गईं
  cross-platform काम ज़्यादातर अलग छोटे teams कर रहे हैं
- मैं Swift की समस्याएँ मानता हूँ, लेकिन “experts नहीं थे” यह कहना बढ़ा-चढ़ाकर कहना है
  Chris Lattner को छोड़ भी दें, तो Swift leads C++ community में मान्यता प्राप्त लोग थे
- Swift का मूल बिंदु भाषा ख़ुद नहीं, बल्कि standard ABI है
  अच्छा होगा अगर Rust ecosystem, C के साथ Swift ABI को भी FFI के लिए support करे
- तो फिर आप किस भाषा की सिफ़ारिश करेंगे, यह जानना चाहूँगा
- क्या Go भी वैसा ही है? आजकल सबसे ज़्यादा सहमति वाला विकल्प क्या माना जाता है, यह जानना चाहता हूँ