최상의 답변
Swift 1, 2, 3은 확실히 “아니요”이지만 Swift 4는 그렇습니다. . 어쨌든 나는 여전히별로 긍정적이지 않습니다.
나는 Rust의 목표 시장이 C / C ++ 프로그래머라고 가정합니다.
Rust의 핵심 기능은 오버 헤드없는 최고의 안전성 . 지금까지 Swift는 여기서 실패했습니다. Swift는 ref-type을 사용할 때 항상 공간과 시간 모두에서 일종의 오버 헤드를 수반합니다. 이것은 필수이며 불가피합니다.
단지 “안전”이 이미 많은 언어에서 제공되고 있기 때문에 오버 헤드가 중요합니다. 예 : C #. 제 생각에는 Swift의 진정한 경쟁자입니다. C #은 이미 특정 수준의 안전을 제공하고 있습니다. 그리고 이미 일부 시장에서 C / C ++를 성공적으로 대체했지만 많은 오버 헤드를 유발하기 때문에 완전히 그런 것은 아닙니다. 공간과 시간 모두에서. Swift 컴파일러는 RC 오버 헤드의 일부를 제거 할 수 있지만 최적화에 대한 운에 달려 있습니다. 불행한 상황에서는 오버 헤드가 커집니다.
안전 수준도 다릅니다. 두 언어 모두 안전한 컨텍스트에서 매달린 포인터가 없음을 보장 할 수 있다는 것은 동일합니다. 하지만 그것이 Swift가 제공 할 수있는 모든 것입니다. 이것은 Rust가 제공하는 것과 비교할 때 매우 약한 보증입니다. 리소스 수준에서 Swift ref 유형은 언제든지 누출 될 수 있으며 항상 사람의주의가 필요합니다. 컴파일러는 순환 참조를 감지 할 수 없습니다. Swift는 또한 스레드간에 변경 가능한 메모리를 무제한으로 공유 할 수 있습니다 (언어 고유의 동시성이 부족하기 때문에). 이는 데이터 경쟁에 대한 안전을 의미하지 않습니다.
반대로, Rust 고유 소유권은 리소스 누출이 없음을 완전히 정적으로 보장합니다. 정적으로 보장되는 데이터 경쟁도 없습니다.
지난 몇 년 동안 Swift를 사용하면서 느낀 점은 리소스 관리 및 데이터 경쟁과 관련하여 언어가 실제로 안전하지 않다는 것입니다. 그리고 필수 RC 오버 헤드는 성능이 중요한 코드에서 실제로 큰 관심사입니다. Swift는 값 유형의 성능을 광고하지만 실제로 힙에 안전하게 할당하려면 항상 일부 참조 유형을 사용해야합니다. Swift는 컴파일러의 스마트 RC 제거를 광고하지만 운을 기반으로합니다. 따라서 비교할 수없는 Rust 비용이 전혀 들지 않습니다.
안전이 중요한 이유는 무엇입니까? 지뢰밭에서는 생산적이지 못하기 때문입니다. 생산성을 높이려면 관심 대상을 줄여야합니다. Swift에서는 아무도 당신을 돌보지 않기 때문에 죽지 않기 위해 항상주기와 데이터 경쟁과 오버 헤드를 돌봐야합니다. Rust에서는 컴파일러가이를 처리 할 수 있습니다. 당신은 단지 (많은) 안전함을 잊고 컴파일러가 불평하는 것을 따르십시오. 그러면 당신은 안전합니다. GC 언어 사용자가 댕글 링 포인터에 신경 쓰지 않는 것처럼.
또한 결정론도 중요합니다. 개체 수명 추적은 거의 필요하지 않지만 때로는 매우 중요합니다. Swift RC는 deinit타이밍을 제공하지만 공유 소유권이기 때문에 일반적으로 죽음의 타이밍이 매우 모호합니다. 고유 소유권의 이러한 타이밍은 RC보다 상대적으로 훨씬 명확합니다.
고유 소유권은 책임 소유자에게 주석을 달아 유지 관리에도 도움이됩니다. 제 생각에는 고유 소유자를 관리하는 것이 여러 소유자를 관리하는 것보다 훨씬 쉽습니다. 실제로 Swift에서 항상하는 일은 암시 적 고유 소유자를 지정하고 규칙에 따라 수동으로 추적하는 것입니다. 컴파일러가이 작업을 수행하면 좋지 않을까요?
Swift 4는 고유 소유권, 이동 의미 체계, 액터 모델 및 C ++ 상호 운용 지원과 같은 몇 가지 새로운 기능을 도입 할 계획입니다. 그러나 나는 그들이 현재 언어 의미 체계의 기능으로 Rust 수준의 안전성을 어떻게 보장 할 수 있는지 잘 모르겠습니다. 그래서 저는 여전히 Swift의 안전 수준에 대해별로 긍정적이지 않습니다. C ++ inter-op은 큰 영업 포인트가 될 수 있습니다. 어쨌든 이것이 내가 Swift 4가 C / C ++ 시장에서 Rust의 잠재적 경쟁자가 될 수 있다고 생각하는 유일한 이유입니다.
Swift도 프로도 있습니다. 예를 들어 (내 의견으로는) 이름 지정 규칙과 명확한 구문 (내 의견으로는), 전용 IDE, 세계에서 가장 부유 한 지지자에 의한 개발 및 지속 가능성 보장 (하지만 지원되는 플랫폼의 정치적 문제도 소개합니다). 전반적으로 더 나은 UI / UX를 가지고 있지만 여전히 Rust의 안전성과 개념적 아름다움에 더 끌립니다…
P.S. 사실 deinit및 weak-ref와 같은 안전한 구조만으로 Swift 2.x 초기 버전에서 매달린 포인터를 만드는 것이 가능했습니다. 하지만 현재와 미래는 확실하지 않습니다.
P.S. 2. 허점을 메운 것 같습니다. Swift 3에서는`deinit`에서 약한 참조를 만들려고하면 런타임 예외가 발생합니다.
Answer
최근 swift-3.x에 대해 읽었지만 저는 꽤 오랜 시간 동안 Rust의 팬이되어 왔고, 저는 Rust가 시스템 언어로 성공하기를 * 정말로 * 원합니다.
당신의 질문에 대한 대답은 조건부 예, 왜입니까? 이는 swift가 네이티브 애플리케이션 프로그래밍 측면에서 rust와 상당한 공간을 겹치기 때문입니다.디자인 철학과 시스템 프로그래밍 (및 일부 실시간 사용 사례)의 사용 사례 측면에서 언어 간에는 뚜렷한 차이가 있습니다.
Rust는 대부분의 부분에서 C ++ 철학에 따라 설계되었습니다. 매우 고성능 컴퓨팅과 엄청나게 최적화 가능한 컴파일러를 수행 할 수 있습니다 (많은 현대 언어가 경쟁하는 것을 보지 못했던 틈새 시장)
- “제로 비용 추상화”
- 이것은 커널이나 핵심 유틸리티를 작성하는 동안 특히 중요한 이유는 성능의 마지막 부분을 얻기 위해 현존하는 최대한으로 최적화해야하기 때문입니다.
- 즉시 대부분의 최적화를 수행 할 수 있지만 전부는 아닙니다. 달성 할 수있는 최적화의 양에 대한 언어 장벽입니다 (예를 들어 대부분의 레퍼런스 카운팅이 신속하게 원자 적이라고 안전하게 가정 할 수 있다고 생각하지만 Rust에서는 Rc 및 Arc 유형 중에서 선택할 수 있으므로 비용을 지불하지 마십시오 사용하지 않는 것).
- “Rust 포인터 모델”
- Rust 프로그램 는 소유권, 차용 및 이동 의미 체계를 통해 코드에서 대부분의 크래시 소스를 제거하도록 설계되었으므로 모든 리소스에 주어진 시점에 고유 한 소유자가 하나만 있는지 정적으로 확인합니다. 이것은 또한 아래 두 가지 사용 사례를 쉽게 만듭니다.
- 프로그램의 충돌 가능성이있는 부분을 분리하는 방법 (안전하지 않음)
- 코드를 작성할 때 안전한 동시성을 유지하는 방법
- li>
- Swift는 강점 (shared\_ptr), 약점 (weak\_ptr) 및 소유되지 않은 포인터 (intrusive\_ptr)를 프로그래머에게 노출하고 그들을 (ab) 사용할 수있는 제어 권한을 부여하기 때문에이 점에서 C ++와 훨씬 더 유사합니다. 코드는 Java보다 확실히 더 잘 제어되지만 안전성은 떨어집니다.
- “Enumerations”
- Rust에는 Haskell의 ADT와 유사한 풍부한 열거 형이 있지만 (그렇게 강력하지는 않지만) 그럼에도 불구하고 FSM 작성을 매우 잘 지원하지 않는 C에 대해 생각한다면 FSM (Finite State Machines)의 아름다운 디자인을 가능하게합니다.
- Swift는 또한 Java와 유사한 아름다운 열거 형을 가지고 있습니다. 열거 형에 대한 동작입니다.
- “Closures”-이것은 현대 언어와 구식 언어를 구별하는 단일 기능입니다. Rust와 Swift는 모두 클로저를 지원하지만 rust 모델을 사용하면 “closed over”변수의 소유권에 대해 추론 할 수 있으므로 안전을 보장 할 수 있습니다. 다른 한편으로는 Swift 클로저가 경험 많은 프로그래머에게도 몇 가지 놀라움을 불러 일으킬 수 있습니다.
- Rust의 문제
- Dubly 연결 목록과 같은 매우 단순한 데이터 구조는 rust에 존재할 수 없습니다. 소유권 의미론 (이 간단한 데이터 구조를 위해 Rc / Arc를 사용하도록 강요 됨)의 이는 일부 사람들을 짜증나게합니다.
- 프로그래밍 경험에 따라 인기있는 언어에 기능이있을 때 사람들은 그것들을 남용하십시오. Rust에서 안전하지 않은 블록은 차용 검사기에 맞서 싸울 의사가없는 사람들에게 확실히 남용되기 쉽습니다. 이는 슬프게도 많은 비율을 차지합니다.
- 불변성이 아닌 경우 표준 라이브러리의 불변성 위반 사소한 코드는 Rust로 작성되어야합니다. 우리는 Cell / RefCell과 같은 데이터 유형이 언어가 제공하는 것처럼 보이는 강력한 안전성에 대한 백도어로 기술적으로 사용될 수 있어야합니다. 라이브러리가 이러한 데이터 유형을 사용하는 동안 많은 안전 프리미티브를 제공하므로 우리가 발을 헛디 디지 않습니다.
- 마지막으로 Rust는 C ++보다 더 안전하지만 일부는이를 인정하는 것 같습니다. 우리가 채택을 허용하고 사람들이 사소하지 않은 코드를 작성할 수 있도록 싫어하는 C ++ 기능도 통합해야합니다. 슬프지만 안타깝게도 사실입니다.
- Swift의 문제점
- 모든 곳에서 ARC의 만연한 사용-이것은 “당신이하지 않는 것에 대해 지불하지 않습니다. C ++의 사용 “철학 (swift 5.x에서 해결 될 수 있음 ( [swift-evolution] RFC : 유지주기 방지 (메모리 소유권 모델) 참조))
- 사용하기 매우 쉬운 비동기 프리미티브 라이브 async / await / coroutines (go와 같은 언어의 판매 포인트)가 부족한 경우 신속하게 5.x가이를 해결할 수 있습니다.
- 때로는 “class ”선언은 실제로 값 유형 (구조체)을 선호 할 수있는 참조 유형을 사용하도록 불필요하게 강제 할 수 있습니다.
- Rust의 특성은 기술적으로 (대부분의 경우) 3 개의 다른 신속한 엔티티 (확장, 프로토콜)에 대한 더 나은 솔루션입니다. & 상속)
그래서 빠른 점유를위한 틈새가 분명히 있다고 생각합니다. 좋은 C ++ 프로그래머 인 사람들은 Swift / Rust에 빠르게 접근 할 수 있습니다.하지만 Swift가 더 많은 관심을 끌 것이라고 생각합니다. 와 함께 애플리케이션 개발자 및 시스템 프로그래머와 함께하는 Rust. 각각의 틈새 시장은 상당한 중복에도 불구하고 계속 존재할 것입니다.