Swift คือ Rust ที่สะดวกกว่า (2023)

• Rust และ Swift ต่างก็มีระบบชนิดข้อมูลที่แข็งแกร่งและมีลักษณะของภาษาฟังก์ชันนัลร่วมกัน อีกทั้งยังสามารถคอมไพล์เป็นเนทีฟโค้ดและ WASM ได้ผ่าน คอมไพเลอร์ที่อิงกับ LLVM
• Rust เริ่มต้นจากภาษาเชิงระบบระดับล่างแล้วค่อยเพิ่มความสามารถระดับสูง ขณะที่ Swift เริ่มจากภาษาระดับสูงแล้วเปิดให้เข้าถึงระดับล่างได้
• Swift ใช้ value type และ Copy-on-Write เป็นพื้นฐาน และนำแนวคิดคล้ายกับ โมเดล ownership ของ Rust มาใช้งานด้วยไวยากรณ์ที่เรียบง่ายกว่า
• ในเรื่อง optional type, การจัดการ error, recursive enum เป็นต้น Swift ได้นำแนวคิดของ Rust มาห่อด้วย ไวยากรณ์แบบตระกูล C ที่คุ้นเคย ทำให้นักพัฒนาใช้งานได้สะดวกยิ่งขึ้น
• Swift กำลังพัฒนาไปเป็น ภาษาข้ามแพลตฟอร์ม และสามารถใช้งานได้บน Windows, Linux และสภาพแวดล้อม embedded จึงกำลัง ก้าวขึ้นมาเป็นทางเลือกของ Rust

---

ความเหมือนและความต่างระหว่าง Rust กับ Swift

• ทั้งสองภาษา ต่างก็มี คุณลักษณะของภาษาฟังก์ชันนัล (tagged enum, match/switch expression, generic, first-class function)
  • Rust มี Rc, Arc, Cow เพื่อรองรับ reference counting และการควบคุมการคัดลอก
  • Swift ใช้ value type และ Copy-on-Write เป็นค่าเริ่มต้น และรองรับ การย้าย ownership (move) กับ การเข้าถึง pointer แบบ unsafe เมื่อจำเป็น
• ทั้งสองภาษาใช้ คอมไพเลอร์ที่อิงกับ LLVM จึงคอมไพล์เป็นเนทีฟโค้ดและ WASM ได้

โมเดลหน่วยความจำ: Rust เป็นแบบบนลงล่าง, Swift เป็นแบบล่างขึ้นบน

• Rust เริ่มจากการเป็น ภาษาเชิงระบบระดับล่าง แล้วเพิ่มความสามารถระดับสูงเข้ามา
• Swift เริ่มจากการเป็น ภาษาระดับสูง แล้วอนุญาตให้เข้าถึงระดับล่างได้เมื่อจำเป็น
• โมเดลหน่วยความจำพื้นฐานของ Swift คือ value type แบบ Copy-on-Write ซึ่งคล้ายกับ Cow<> ของ Rust
  • Rust เร็วเป็นค่าเริ่มต้น แต่เมื่อใช้งานต้องจัดการ Cow<> อย่างชัดเจน
  • Swift เรียบง่ายเป็นค่าเริ่มต้น และสามารถเลือกย้ายแทนการคัดลอกได้

แนวทางเชิงไวยากรณ์ของ Swift: ซ่อนแนวคิดของ Rust ไว้ด้วยสไตล์ C

• คำสั่ง switch ของ Swift ทำงานเทียบได้กับ expression match ของ Rust แทบทั้งหมด
  • รองรับ pattern matching และไม่มี fallthrough
• enum ของ Swift สามารถ ใส่เมธอดไว้ภายในได้โดยตรง จึงใช้งานเชิงวัตถุได้มากกว่า Rust
• optional type (T?) เป็นแนวคิดเดียวกับ Option<T> ของ Rust โดย nil เทียบได้กับ None
  • ใน Swift สามารถ unwrapping อย่างปลอดภัยได้ด้วยไวยากรณ์ if let val
• การจัดการ error คล้ายกับชนิด Result ของ Rust และ do-catch กับ try ของ Swift ก็เป็น โครงสร้างเดียวกันที่ถูกห่อด้วยไวยากรณ์ที่คุ้นเคย

ความต่างของการทำงานของคอมไพเลอร์

• คอมไพเลอร์ Rust ให้ความสำคัญกับ การตรวจพบปัญหาและคำเตือน เช่น ในการประกาศ recursive enum จะบังคับให้ใช้ Box<>
• Swift จัดการ recursive enum ได้ด้วยคีย์เวิร์ด indirect เพียงอย่างเดียว และ คอมไพเลอร์จะจัดการ pointer ภายในให้อัตโนมัติ
• Swift มี การทำงานอัตโนมัติ มากกว่า Rust ทำให้นักพัฒนาไม่ต้องจัดการโครงสร้างหน่วยความจำด้วยตัวเองมากนัก

ความเป็นภาคปฏิบัติและความยืดหยุ่นในการขยายภาษาของ Swift

• Swift ถูกออกแบบมาเพื่อ แทนที่ Objective-C จึงเป็น ภาษาที่ใหญ่กว่าและเน้นใช้งานจริงมากกว่า
  • มีฟีเจอร์ในตัวหลากหลาย เช่น class/inheritance, async-await, actors, lazy property, property wrappers, Result Builders
• การออกแบบแบบ “progressive disclosure” ทำให้ยิ่งเรียนรู้มากขึ้น ก็ยิ่งพบความสามารถเพิ่มเติมของภาษา

สมดุลระหว่างความสะดวกและประสิทธิภาพ

• Swift เป็น ภาษาที่เริ่มต้นง่ายและทำงานได้อย่างมีผลิตภาพ ขณะที่ Rust เป็น ภาษาที่เร็วเป็นค่าเริ่มต้น
  • Rust คือ “เร็วเป็นค่าเริ่มต้น” ส่วน Swift คือ “สะดวกเป็นค่าเริ่มต้น”
• Rust เหมาะกับ ระบบ, embedded, คอมไพเลอร์, browser engine
• Swift เหมาะกับ UI, เซิร์ฟเวอร์, และบางองค์ประกอบของระบบปฏิบัติการ และ ขอบเขตการใช้งานของทั้งสองภาษาก็กำลังทับซ้อนกันมากขึ้น

การขยายตัวข้ามแพลตฟอร์มของ Swift

• Swift ไม่ใช่ ภาษาเฉพาะของ Apple อีกต่อไป
  • Windows: The Browser Company ใช้ในการแชร์โค้ดของเบราว์เซอร์ Arc
  • Linux: Apple สนับสนุน Swift on Server และเป็นสปอนเซอร์งานคอนเฟอเรนซ์
  • Embedded Swift: ใช้งานบนอุปกรณ์ขนาดเล็กอย่าง Panic Playdate ได้
• บล็อกทางการของ Swift ได้แนะนำโครงการ Windows, Embedded, Linux(Gnome), Playdate
• Swift กำลังพัฒนาประสบการณ์การพัฒนาให้ดีขึ้นนอกเหนือจาก Xcode ด้วย ส่วนขยาย VSCode, การโอเพนซอร์ส LSP เป็นต้น

ข้อจำกัดและตำแหน่งปัจจุบันของ Swift

• เวลาในการคอมไพล์ ยังช้าเหมือนกับ Rust
• ภาษาใหญ่ขึ้นจาก feature creep และไวยากรณ์บางส่วนก็ยังไม่คุ้นเคย
• ระบบนิเวศแพ็กเกจ ยังไม่สมบูรณ์เท่า Rust
• อย่างไรก็ตาม Swift ก็มีทั้ง ABI stability, automatic reference counting (ARC), ฟีเจอร์การเลือก ownership, และ แพ็กเกจที่รองรับ Linux แล้ว ในฐานะ ภาษาข้ามแพลตฟอร์ม
• Swift กำลังยืนตำแหน่งเป็น ทางเลือกที่สะดวกกว่า Rust และเป็น ตัวเลือกที่มีอยู่ในปัจจุบัน ไม่ใช่อนาคตที่ต้องรอ

[GN⁺]

ความเห็นจาก Hacker News

• โดยรวมเห็นด้วย แต่ในรายละเอียดกลับเผยให้เห็น แก่นของปัญหา
  Xcode เป็น IDE ที่ยังหยาบ ซึ่งมักค้างในโปรเจ็กต์ขนาดใหญ่เวลารีเฟรชแพ็กเกจหรือจัดการหลาย target และถึงอยากแก้ก็แพตช์ไบนารีไม่ได้
  ระบบ build นั้น Cargo ใช้ง่ายกว่า SPM มาก ส่วนระบบ macro ก็ยังคงพึ่งพาการสร้างโค้ดจากภายนอก
  มีทั้ง linter และ formatter แต่คุณภาพต่ำ Swift มี performance cliff เยอะ และเพราะ type inference เป็นแบบสองทิศทางจึงช้าเมื่อเจอนิพจน์ซับซ้อน โดยเฉพาะในกรณีใช้งานหลักอย่าง SwiftUI
  การ import ถูกผูกไว้ระดับโมดูล ทำให้แค่เปลี่ยนไฟล์เดียวก็ต้องคอมไพล์ทั้งโมดูลใหม่ อีกทั้งการแยกระหว่าง class กับ struct ก็ดูฝืนเพราะต้องเข้ากันได้กับ ObjC
  สุดท้าย Swift อาจเป็นภาษาที่ง่ายกว่า Rust ได้ แต่ในทางปฏิบัติกลับไม่รู้สึกเช่นนั้นเพราะ ecosystem ด้านเครื่องมือยังไม่สุกงอม

  • เคยทำแอป SwiftUI เล็ก ๆ แล้วพบว่าไล่หา memory leak ยากมาก ถึงจะใช้ Instruments กับ vmmap วิเคราะห์ก็ยังรั่ววันละหลายสิบ MB
    โมเดลหน่วยความจำแบบกึ่งอัตโนมัติของ Swift รู้สึกว่าจัดการยากกว่า Rust หรือ Go มาก
  • ถ้าไม่ได้ทำแอป iOS/macOS ก็ข้าม Xcode ไปใช้แค่ swift CLI ได้เลย และใช้งานบน Linux กับ Windows ได้ดีพอสมควร
  • Swift รองรับ LSP จึงพัฒนาใน VSCode, Zed, Sublime Text ฯลฯ ได้ ถ้าไม่ได้พัฒนาเฉพาะบน Apple ก็ไม่จำเป็นต้องใช้ Xcode
  • Swift ยุคก่อนเคยมีกรณีที่แค่ dictionary literal ไม่กี่บรรทัดก็ทำให้ build นาน 30 นาที
  • ปัญหาความเร็วในการคอมไพล์ส่วนใหญ่บรรเทาได้ด้วยการ แยกเป็นแพ็กเกจ และระบุ type แบบชัดเจน SPM ทำงานได้ดีกว่าที่คิด

• มีคนบอกว่าการแทนโครงสร้างต้นไม้ใน Rust ด้วย enum ต้องใช้ Box แต่จริง ๆ แล้ว Vec ก็ให้การอ้างอิงบน heap อยู่แล้วจึงไม่จำเป็น

  • เพราะเข้าใจ Rust ดีอยู่แล้วจึงไม่ได้ติดใจกับความผิดพลาดนี้ แต่ก็ทำให้กังวลว่าคำอธิบายฝั่ง Swift อาจผิดแบบเดียวกันหรือไม่
    ทั้ง enum, struct, union ของ Rust ไปจนถึง ชนิดข้อมูลพื้นฐาน ก็มีเมธอดได้ทั้งหมด เช่นเรียก 'F'.to_digit(16) ได้
    แม้แต่ raw pointer ก็ยังเพิ่มเมธอดได้ ซึ่งมองว่านี่คือการออกแบบที่ทันสมัยของ Rust
  • มีการยก enum ของ Swift มาเป็นตัวอย่างว่ามี syntactic sugar ที่ดี แต่จริง ๆ แล้วการรองรับ union type ยังอ่อน ทำให้นักพัฒนาหลายคนใช้ optional แทน enum มากเกินไป
  • สับสนความต่างระหว่าง Vec กับ Box ได้ง่าย Vec เป็น handle ที่มีขนาดคงที่ตอนคอมไพล์ ส่วน Box จำเป็นเมื่อจัดการ unsized type
  • ลองทดสอบกับ Rust 1.92 แล้ว พบว่าทำงานได้ดีโดยไม่ต้องมี Box
  • ตัว Vec<T> เองก็เป็น handle ขนาดคงที่ที่ชี้ไปยังข้อมูลบน heap อยู่แล้ว จึงไม่ต้องใช้ Box

• Swift เป็นภาษาที่ดี แต่บนฝั่ง server-side ยังไม่ค่อยน่าเชื่อถือ
  ecosystem เล็ก และเทียบกับ Go หรือ Rust แล้วไม่ได้อะไรเพิ่ม การรองรับ VSCode ก็ยังไม่ดีนัก และก็ไม่อยากใช้ Xcode
  งานพัฒนาเซิร์ฟเวอร์ถูก Python, TypeScript, Go และ Rust จับจองไปแล้ว ecosystem แบบปิดของ Apple ก็เป็นภาระอีกอย่าง

  • เคยมีประสบการณ์ทำแบ็กเอนด์ด้วย Swift โดย เชื่อมกับ C library โดยตรง จริง ๆ มันทำงานได้ดีแม้ไม่มี FFI และประสิทธิภาพก็ดี
    คุณภาพ IDE ดีกว่าภาษาอื่น แต่ถ้าเป็น system programming ก็ยังมองว่า Rust เหมาะกว่า
  • เคยทำโปรเจ็กต์ส่วนตัวด้วย Swift Vapor แต่รู้สึกเสียดายที่ ความเร็วในการคอมไพล์และการทดสอบ ช้ากว่า Go

• แม้ตอนนี้ Swift จะถูกเรียกว่าเป็น ภาษาแบบข้ามแพลตฟอร์ม แต่บน Linux ก็ยังเป็น ecosystem ที่ยึด Apple เป็นศูนย์กลาง
  ทั้งเอกสาร ทิวทอเรียล และไลบรารีต่างเขียนโดยอิง macOS เป็นหลัก เลยสงสัยว่ามีคนใช้ Swift โดยไม่มีอุปกรณ์ Apple จริงหรือไม่

  • เอกสารของ Apple ไม่ได้ระบุข้อจำกัดบน Linux ไว้อย่างชัดเจน ทำให้ต้องลองผิดลองถูกเยอะ
    เคยสรุปประสบการณ์ตอนทำ WebSocket client ไว้ในบล็อก
    เวอร์ชันปี 2023 / เวอร์ชันปี 2025
  • นักพัฒนาฝั่ง Apple อาจบอกว่าบน Linux ก็ดี แต่ในความเป็นจริง ecosystem ของ Rust เหนือกว่ามาก
  • เคยพยายามย้ายเครื่องมือ CLI สำหรับ Mac ไปลง Linux แต่กลับพบว่าให้ LLM แปลงเป็นโค้ด Go เร็วและง่ายกว่า
    การรองรับ Android ก็น่าสนใจ แต่ก็รู้สึกว่า Kotlin เพียงพออยู่แล้ว
  • ตัวอย่างที่อิง Apple มากเกินไปทำให้เกิด ปัญหาเวลา cross-compile เช่น NSHashTable ไม่มีอยู่บนแพลตฟอร์มนอก Apple
  • Swift มีเครื่องมือ swiftly สำหรับจัดการเวอร์ชันคอมไพเลอร์คล้าย rustup และ LSP ก็ทำงานได้ดี
    ส่วนตัวก็ดูแลไลบรารีให้รองรับถึง Windows อยู่ แม้ยังไม่สมบูรณ์แต่ก็ค่อย ๆ ดีขึ้น

• switch ของ Swift แท้จริงแล้วแทบจะเป็น match expression เพียงแต่ไวยากรณ์ต่างกันและยังคงทำ pattern matching เหมือนเดิม

  • ถ้ามองจากฝั่งนักออกแบบภาษา นี่ดูเป็นกลยุทธ์ในการคงไวยากรณ์ switch เดิมไว้เพื่อ ลดความสับสนของนักพัฒนา
    เป็นการนำความหมายใหม่เข้ามาผ่านไวยากรณ์ที่คุ้นเคย เพื่อให้เปลี่ยนผ่านอย่างค่อยเป็นค่อยไป
    แนวทางแบบนี้นำไปสู่ประเด็นถกเถียงที่น่าสนใจว่าภาษาควรมี การออกแบบที่ชี้นำอย่างชัดเจน มากแค่ไหน

• แกนหลักของ Rust คือ zero-cost abstraction ซึ่ง Swift ไม่ได้ยึดตามหลักการนี้
  ฟีเจอร์จำนวนมากของ Rust ถูกออกแบบมาเพื่อรักษากฎข้อนี้ไว้ และ โมเดล ownership คือหนึ่งในตัวอย่างเด่น

  • โมเดล ownership แบบชัดเจนของ Rust ช่วย ป้องกันข้อผิดพลาดรันไทม์ตั้งแต่ตอน build ซึ่งอาจเกิดขึ้นได้ใน actor หรือ Task ของ Swift
    แม้มีช่วงเรียนรู้ที่ชัน แต่ก็ช่วยเพิ่มประสิทธิภาพการพัฒนา
  • Swift ก็รองรับโมเดล ownership เช่นกัน แต่ไม่ได้บังคับใช้อย่างเข้มงวดเท่า Rust

• มีการบอกว่า Arc browser ใช้ Swift บน Windows แต่หลังจาก หยุดพัฒนา ก็ดูเหมือนว่างานที่เกี่ยวข้องจะถูกยกเลิกไปด้วย

  • ถึงอย่างนั้น Swift for Windows ก็ยังมีอยู่ และยังมีทั้งหน้าติดตั้งอย่างเป็นทางการกับ Windows Workgroup ที่ยังดำเนินงานอยู่

• เหตุผลที่ชอบ Rust มากกว่าคือ ไม่ขึ้นกับบริษัทยักษ์ใหญ่ เลยมองว่า Apple อาจทิ้ง Swift ก็ได้

  • แต่ความเป็นไปได้ที่ Apple จะทิ้ง Swift นั้นต่ำ Rust เองอาจเสี่ยงกว่าเสียอีกเพราะพึ่งพาชุมชนมากกว่า
  • ซอฟต์แวร์ส่วนใหญ่ของ Apple เขียนด้วย Swift อยู่แล้ว จึงไม่มีเหตุผลให้เลิกใช้
  • Go ก็ผูกกับ Google, C# ก็ผูกกับ Microsoft ส่วน Swift ก็เป็นโอเพนซอร์ส จึงรู้สึกว่ายากจะวิจารณ์ด้วยตรรกะเดียวกัน
  • Swift ถูกสร้างโดย Apple ก็จริง แต่ ชุมชนโอเพนซอร์สเป็นผู้ดูแลต่อ
    มีระบุไว้ชัดเจนใน บทความวิกิ

• หากใช้ความสามารถด้าน reference counting ของ Rust ก็อาจได้ความสะดวกโดยไม่ต้องย้ายไป Swift
  ใช้ Rc สำหรับ immutable shared reference และใช้ interior mutability เพื่อให้แก้ไขได้ด้วยการตรวจสอบตอนรันไทม์
  เอกสาร Rc, เอกสาร interior mutability

  • ในสภาพแวดล้อมแบบ single-thread ใช้ Rc ส่วนแบบ multithread ใช้ Arc และด้วย Send trait จึงไม่เกิดการใช้ Rc บน thread ที่ผิด
  • แต่ข้อเสียคือโค้ดจะ ยืดยาวเกินไป

• เคยสร้าง เครื่องมือวิเคราะห์และคอมไพเลอร์ สำหรับ Linux ด้วยทั้ง Swift และ Rust
  Swift จัดการหน่วยความจำได้สะดวกเพราะ ARC ส่วน Rust ต้องคิดมากกว่า แต่ คุณภาพของเครื่องมือพัฒนา ดีกว่ามาก
  Clippy และการรองรับ LSP ยอดเยี่ยม ขณะที่ Swift มีฟังก์ชันพื้นฐานที่ให้มาครบ
  อย่างไรก็ดีเพราะชุมชน Rust ใหญ่กว่า จึงหาคนร่วมงานได้ง่ายกว่า และก็มองว่า Swift เองก็มีศักยภาพในฐานะ ภาษาทดแทน C++