▲

Swift는 더 편리한 Rust (2023)

 (nmn.sh)
2P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • Rust와 Swift는 모두 강력한 타입 시스템과 함수형 언어의 특징을 공유하며, LLVM 기반 컴파일러를 통해 네이티브 코드와 WASM으로 컴파일 가능
  • Rust는 하위 수준 시스템 언어로 시작해 상위 수준 기능을 제공하고, Swift는 상위 수준 언어로 시작해 하위 수준 접근을 허용
  • Swift는 값 타입과 Copy-on-Write를 기본으로 하며, Rust의 소유권 모델과 유사한 개념을 더 단순한 문법으로 구현
  • 옵셔널 타입, 에러 처리, 재귀 enum 등에서 Swift는 Rust의 개념을 C 계열 친숙한 문법으로 감췄으며, 개발자에게 더 높은 편의성 제공
  • Swift는 크로스플랫폼 언어로 발전 중이며, Windows·Linux·임베디드 환경에서도 사용 가능해 Rust의 대안으로 부상

Rust와 Swift의 유사성과 차이

  • 두 언어 모두 함수형 언어의 특징(태그된 enum, match/switch 표현식, 제네릭, 1급 함수)을 포함
    • Rust는 Rc, Arc, Cow를 통해 참조 카운팅과 복제 제어를 제공
    • Swift는 기본적으로 값 타입과 Copy-on-Write를 사용하며, 필요 시 소유권 이동(move) 과 unsafe 포인터 접근 지원
  • 두 언어 모두 LLVM 기반 컴파일러를 사용해 네이티브 코드와 WASM으로 컴파일 가능

메모리 모델: Rust는 하향식, Swift는 상향식

  • Rust는 저수준 시스템 언어로 시작해 상위 수준 기능을 제공
  • Swift는 상위 수준 언어로 시작해 필요 시 저수준 접근을 허용
  • Swift의 기본 메모리 모델은 Copy-on-Write 값 타입, Rust의 Cow<>와 유사
    • Rust는 기본적으로 빠르지만 사용 시 Cow<>를 명시적으로 처리해야 함
    • Swift는 기본적으로 단순하며, 복사 대신 이동을 선택할 수 있음

Swift의 문법적 접근: Rust 개념을 C 스타일로 감춤

  • Swift의 switch 문은 사실상 Rust의 match 표현식과 동일한 기능을 수행
    • 패턴 매칭을 지원하며, fallthrough가 없음
  • Swift의 enum은 메서드를 직접 포함할 수 있어 Rust보다 객체지향적 사용 가능
  • 옵셔널 타입(T?) 은 Rust의 Option<T>와 동일한 개념으로, nil은 None에 해당
    • Swift에서는 if let val 구문으로 안전하게 언래핑 가능
  • 에러 처리는 Rust의 Result 타입과 유사하며, Swift의 do-catch와 try는 익숙한 문법으로 감싼 동일한 구조

컴파일러 동작의 차이

  • Rust 컴파일러는 문제 탐지와 경고에 중점을 두며, 예를 들어 재귀 enum 정의 시 Box<> 사용을 강제
  • Swift는 indirect 키워드만으로 재귀 enum을 처리하며, 컴파일러가 내부 포인터 관리 자동화
  • Swift는 Rust보다 자동화된 처리가 많아 개발자가 직접 메모리 구조를 다룰 필요가 적음

Swift의 실용성과 언어 확장성

  • Swift는 Objective-C 대체를 목표로 설계되어 더 크고 실용적인 언어
    • 클래스/상속, async-await, actors, lazy 속성, property wrappers, Result Builders 등 다양한 기능 내장
  • “점진적 공개(progressive disclosure) ” 설계로, 학습이 진행될수록 더 많은 기능이 드러남

편의성과 성능의 균형

  • Swift는 시작과 생산성이 쉬운 언어, Rust는 기본적으로 빠른 언어
    • Rust는 “빠름이 기본”, Swift는 “편의가 기본”
  • Rust는 시스템·임베디드·컴파일러·브라우저 엔진에 적합
  • 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는 VSCode 확장, LSP 오픈소스화 등으로 Xcode 외 환경에서도 개발 경험 개선 중

Swift의 한계와 현재 위치

  • 컴파일 시간은 Rust와 마찬가지로 느림
  • 기능 확장(feature creep) 으로 언어가 커졌으며, 일부 문법은 익숙하지 않음
  • 패키지 생태계는 Rust보다 미성숙
  • 그러나 Swift는 이미 ABI 안정성, 자동 참조 카운팅(ARC) , 소유권 선택 기능, Linux 호환 패키지를 갖춘 크로스플랫폼 언어
  • Swift는 Rust보다 편리한 대안으로 자리 잡고 있으며, 기다릴 미래가 아닌 현재의 선택지로 존재
▲
GN⁺ 1일전  [-]
Hacker News 의견들

  • 대부분 동의하지만, 세부적인 부분에서 문제의 핵심이 드러남
    Xcode는 대규모 프로젝트에서 패키지 새로고침이나 다중 타깃 처리 시 자주 멈추는 거친 IDE임. 수정하려 해도 바이너리 패치가 불가능함
    빌드 시스템은 Cargo가 SPM보다 훨씬 다루기 쉬움. 매크로 시스템은 여전히 외부 코드 생성에 의존함
    린터와 포매터는 존재하지만 품질이 낮음. Swift에는 성능 절벽이 많고, 타입 추론이 양방향이라 복잡한 표현식에서 느려짐. SwiftUI 같은 주요 사용 사례에서 특히 문제임
    모듈 단위로 import가 묶여 있어 파일 하나만 바꿔도 전체 모듈을 다시 컴파일해야 함. 클래스와 구조체의 구분도 ObjC 호환성 때문에 어색함
    결국 Swift가 Rust보다 쉬운 언어가 될 수는 있지만, 도구 체계의 미성숙 때문에 실제로는 그렇지 않다고 느낌

    • 작은 SwiftUI 앱을 만들었는데 메모리 누수를 찾기가 너무 어려웠음. Instruments와 vmmap으로 분석해도 하루에 수십 MB씩 새어나감
      Swift의 반자동 메모리 모델이 Rust나 Go보다 훨씬 다루기 어렵다고 느낌
    • iOS/macOS 앱이 아니라면 Xcode를 완전히 건너뛰고 swift CLI만 써도 충분히 괜찮음. Linux와 Windows에서도 잘 동작함
    • Swift는 LSP를 지원하므로 VSCode, Zed, Sublime Text 등에서도 개발 가능함. Apple 전용 개발이 아니라면 Xcode는 필수가 아님
    • 예전 Swift에서는 딕셔너리 리터럴 한두 줄 때문에 빌드가 30분 걸린 적이 있었음
    • 대부분의 컴파일 속도 문제는 패키지 단위 분리와 명시적 타입 지정으로 완화 가능함. SPM은 생각보다 괜찮게 작동함

  • Rust에서 트리 구조를 enum으로 표현할 때 Box가 필요하다고 했지만, 실제로는 Vec이 이미 힙 참조를 제공하므로 불필요함

    • Rust를 잘 알고 있어서 오류 자체는 신경 안 쓰지만, Swift 쪽 설명도 비슷하게 틀렸을까 걱정됨
      Rust의 enum, struct, union, 심지어 원시 타입까지 모두 메서드를 가질 수 있음. 예를 들어 'F'.to_digit(16) 같은 호출이 가능함
      심지어 raw pointer에도 메서드를 붙일 수 있음. 이런 점이 Rust의 현대적인 설계라고 생각함
    • Swift의 enum을 예로 들며 문법적 설탕이 좋다고 하지만, 실제로는 union 타입 지원이 약해서 많은 개발자가 enum 대신 optional을 남용함
    • Vec과 Box의 차이를 혼동하기 쉬움. Vec은 컴파일 시 크기가 고정된 핸들이고, Box는 unsized 타입을 다룰 때 필요함
    • Rust 1.92에서 테스트해보니 Box 없이도 잘 작동함
    • Vec<T> 자체가 힙 데이터를 가리키는 고정 크기 핸들이므로 Box가 필요 없음

  • Swift는 멋진 언어지만 서버 사이드에서는 설득력이 약함
    생태계가 작고, Go나 Rust에 비해 얻을 게 없음. VSCode 지원도 미흡하고 Xcode는 쓰고 싶지 않음
    서버 개발은 이미 Python, TypeScript, Go, Rust가 차지하고 있음. Apple의 폐쇄적 생태계도 부담임

    • 실제로 Swift로 C 라이브러리와 직접 연동해 백엔드를 만든 경험이 있음. FFI 없이도 잘 작동했고 성능도 좋았음
      다른 언어보다 IDE 품질이 뛰어나고, 시스템 프로그래밍은 Rust가 더 적합하다고 생각함
    • Swift Vapor로 개인 프로젝트를 해봤는데, Go보다 컴파일·테스트 속도가 느려서 아쉬웠음

  • Swift가 이제는 크로스플랫폼 언어라고 하지만, Linux에서는 여전히 Apple 중심 생태계임
    문서, 튜토리얼, 라이브러리 모두 macOS 기준으로 작성되어 있음. 실제로 Apple 기기 없이 Swift를 쓰는 사람 있나 궁금함

    • Apple 문서에는 Linux 제약이 명시되어 있지 않아 시행착오가 많았음
      WebSocket 클라이언트를 만들며 겪은 과정을 블로그에 정리했음
      2023년 버전 / 2025년 버전
    • Apple 개발자들은 Linux에서도 좋다고 하지만, 실제로는 Rust의 생태계가 훨씬 뛰어남
    • Mac용 CLI 도구를 Linux로 옮기려 했지만, LLM으로 Go 코드로 변환하는 게 더 빠르고 쉬웠음
      Android 지원도 흥미롭지만 Kotlin으로 충분하다고 느낌
    • Apple 중심의 예제가 많아 교차 컴파일 시 문제가 생김. 예를 들어 NSHashTable은 Apple 외 플랫폼에서 존재하지 않음
    • Swift는 rustup과 유사한 swiftly 도구로 컴파일러 버전 관리가 가능하고, LSP도 잘 작동함
      개인적으로 Windows까지 지원하도록 라이브러리를 관리하고 있음. 완벽하진 않지만 점점 나아지는 중임

  • Swift의 switch는 사실상 match 표현식임. 문법만 다를 뿐 패턴 매칭을 수행함

    • 언어 설계자 입장에서는 기존 switch 문법을 유지해 개발자 혼란을 줄이려는 전략으로 보임
      익숙한 문법으로 새로운 의미를 도입해 점진적 전환을 유도한 것임
      이런 접근은 언어가 얼마나 의견이 강한 설계를 추구해야 하는가에 대한 흥미로운 논의로 이어짐

  • Rust의 핵심은 zero-cost abstraction임. Swift는 이 원칙을 따르지 않음
    Rust의 많은 기능은 이 규칙을 지키기 위해 설계되었고, 소유권 모델이 대표적임

    • Rust의 명시적 소유권 모델은 Swift의 actor나 Task에서 발생할 수 있는 런타임 오류를 빌드 타임에 방지함
      학습 곡선은 있지만, 개발 효율을 높여줌
    • Swift도 소유권 모델을 지원하지만 Rust만큼 강제적이지 않음

  • Arc 브라우저가 Windows용 Swift를 사용했다고 하지만, 개발 중단 이후 관련 작업도 취소된 듯함

  • Rust를 선호하는 이유는 대기업 종속성이 없기 때문임. Apple이 Swift를 버릴 수도 있다고 생각함

    • 하지만 Apple이 Swift를 버릴 가능성은 낮음. Rust가 오히려 커뮤니티 의존도가 높아 더 위험할 수도 있음
    • Apple의 대부분 소프트웨어가 Swift로 작성되어 있어 포기할 이유가 없음
    • Go도 Google, C#도 Microsoft에 묶여 있음. Swift도 오픈소스이므로 같은 논리로 비판하기 어렵다고 생각함
    • Swift는 Apple이 만들었지만 오픈소스 커뮤니티가 유지하고 있음
      위키 문서에도 명시되어 있음

  • Rust의 참조 카운팅 기능을 활용하면 Swift로 옮기지 않아도 편리함을 얻을 수 있음
    Rc로 불변 공유 참조를, 내부 가변성으로 런타임 체크 기반의 변경을 구현 가능함
    Rc 문서, 내부 가변성 문서

    • 단일 스레드 환경에서는 Rc를, 멀티스레드에서는 Arc를 사용함. Send 트레이트 덕분에 Rc를 잘못된 스레드에서 쓰는 일은 없음
    • 하지만 코드가 너무 장황해지는 단점이 있음

  • Swift와 Rust로 Linux용 분석 도구와 컴파일러를 만들어봤음
    Swift는 ARC 덕분에 메모리 관리가 편하고, Rust는 더 많은 사고를 요구하지만 툴링 품질이 훨씬 좋음
    Clippy와 LSP 지원이 훌륭하고, Swift는 기본 제공 기능이 많음
    다만 Rust 커뮤니티가 더 크기 때문에 사람을 구하기 쉽고, Swift도 C++ 대체 언어로서 가능성이 있다고 봄

답변달기