- Swift, Apple platforms के अलावा Linux और Windows आदि को भी सपोर्ट करता है
- Swift Static Linux SDK का उपयोग करने पर बाहरी dependencies के बिना पूरी तरह statically linked executable फ़ाइल बनाई जा सकती है
- इसका मतलब है कि यह सभी Linux distributions पर चल सकती है
- macOS पर development और testing करने के बाद इसे Linux-आधारित servers पर deploy किया जा सकता है
- Linking वह प्रक्रिया है जिसमें कंप्यूटर प्रोग्राम के अलग-अलग हिस्सों को लाकर references को जोड़ा जाता है
- static linking build समय पर होती है, जबकि dynamic linking runtime पर होती है
- static libraries अलग-अलग object files का संग्रह होती हैं, जबकि dynamic libraries monolithic होती हैं
- static linking के फायदे और नुकसान:
- फायदे: runtime overhead नहीं, केवल ज़रूरी library code शामिल होता है, अलग से installed dynamic libraries की ज़रूरत नहीं, runtime version issues नहीं
- नुकसान: code sharing संभव नहीं (memory usage बढ़ता है), program को rebuild किए बिना dependencies update नहीं की जा सकतीं, executable फ़ाइल का आकार बढ़ता है
- Linux पर static linking इस्तेमाल करने से distribution के अनुसार system library dependencies को पूरी तरह हटाया जा सकता है
- swift.org से Open Source toolchain install करनी होगी (Xcode द्वारा दी गई toolchain का उपयोग नहीं किया जा सकता)
swift sdk install कमांड से Static Linux SDK install किया जा सकता है
swift build --swift-sdk x86_64-swift-linux-musl कमांड से x86-64 Linux binary, और swift build --swift-sdk aarch64-swift-linux-musl कमांड से ARM64 Linux binary बनाई जा सकती है
- Foundation या Swift NIO का उपयोग करने वाले Swift packages वैसे ही काम करते हैं
- C libraries का उपयोग करने वाले packages में Glibc की जगह Musl को import करने के लिए बदलाव करना होगा
- Musl static linking को अच्छी तरह सपोर्ट करता है और executable distribution को आसान बनाने वाला permissive license रखता है
swift package edit कमांड से package dependencies में बदलाव किया जा सकता है
2 टिप्पणियां
अब इसे इस्तेमाल करके Swift के साथ Android और iOS का एक साथ डेवलपमेंट और ज़्यादा seamless तरीके से सपोर्ट करने वाली कोई चीज़ आने का एहसास हो रहा है ..
Hacker News की राय
Swift का नया custom platform support: Swift का embedded systems और WASM को support करना, और उसका non-Apple GitHub organization में जाना, Swift को दूसरे platforms तक बढ़ाने की दिशा में बड़ा कदम है। AI OS security verification में इसके इस्तेमाल की संभावना भी दिलचस्प है.
Swift binaries को Alpine container में चलाना संभव: यह देखकर खुशी है कि अब Swift binaries को Alpine container में चलाया जा सकता है। musl support पर काम उम्मीद से तेज़ बढ़ा है। cross-compilation भी बहुत उपयोगी है.
Debian support को लेकर उम्मीद: Debian में Swift packages जुड़ते देखना अच्छा लगेगा। लगता है development VM के रूप में Debian का और ज़्यादा उपयोग होगा.
Embedded systems में Swift इस्तेमाल करने की उम्मीद: embedded systems में C का बहुत इस्तेमाल किया है, लेकिन STM development board पर Swift आज़माना चाहूँगा.
Static linking के नुकसान: ASLR या तो सही से काम नहीं करता, या केवल एक object ही randomize होता है। memory-safe language में यह बहुत बड़ी कमी न भी हो सकती है। shared objects बाँटने से I/O कम हो सकता है.
Distributions के बीच compatibility issues: किसी खास distribution या version पर बना program किसी दूसरे distribution पर काम न करे, ऐसा हो सकता है। Swift का static linking देना अच्छा है, लेकिन सबसे अच्छा यही है कि distributions खुद तय कर सकें कि packages कैसे distribute करने हैं.
Golang से प्रतिस्पर्धा की संभावना: deployment की आसानी के मामले में Swift, Golang से मुकाबला कर सकता है। यह complexity को end user से दूर धकेल देता है.
Cross-platform GUI apps: सोचता हूँ Swift से cross-platform GUI apps बनाना कैसा होगा। शायद SwiftUI इस्तेमाल नहीं किया जा सकेगा, लेकिन मैं Swift का उपयोग simple scripting के लिए करने वाला हूँ.
CentOS 7 image इस्तेमाल करने की चेतावनी: अभी भी CentOS 7 images देना पागलपन जैसा लगता है। इसे इस्तेमाल न करने की चेतावनी है.
Swift की बढ़ती complexity: Swift आसानी से Python की जगह ले सकता था, लेकिन language इतनी complex हो गई है कि अब यह C++ की नकल जैसा लगने लगा है.
Rust की जगह Swift क्यों: यह सवाल कि Rust के बजाय Swift क्यों इस्तेमाल किया जाए.
iOS/SwiftUI के बिना Swift क्यों: यह सवाल कि iOS/SwiftUI के बिना Swift इस्तेमाल करने की कोई वजह है भी या नहीं। Swift developers अगर छोटे projects में अपनी जानी-पहचानी language इस्तेमाल करना चाहें, तो उसके अलावा शायद कोई खास वजह नहीं दिखती.