GN⁺ 1달전 | parent | ★ favorite | on: Swift 6.3 릴리즈(swift.org)
Hacker News 의견들
  • Swift로 이렇게 멋진 릴리스가 나오는 걸 보니 반가움
    예전 v3 이후로는 안 써봤지만, 2015~17년 즈음에는 Swift가 Python을 대체할 수도 있었음
    단순하고 빠르며 C/C++ 생태계와도 잘 맞았기 때문임. IBM이 서버 쪽을 밀던 시절엔 진짜 가능성이 있었음
    하지만 Apple이 커뮤니티를 충분히 끌어들이지 못했고, 결국 Swift는 Apple 전용 언어로 남게 되었음. 지금은 복잡성도 C++ 수준으로 올라감

    • 대학 시절 프리랜서로 일하면서 Swift로 웹 백엔드를 만들었음. Heroku 빌드팩으로 배포했는데 꽤 재밌는 시기였음
      Swift를 좋아하지만, Apple 생태계 밖에서는 아직 임계점을 넘지 못한 느낌임. 결국 작년에 Typescript로 전환했음
    • 최신 Swift 6.3을 써도 Apple 플랫폼 외의 개발은 여전히 고통스러움
      무엇보다 Apple이라는 게이트키퍼를 스택에 자발적으로 들이고 싶어 하는 사람은 거의 없을 것 같음
    • Google도 한때 TensorFlow를 Python에서 Swift로 옮기려 했었음
      TensorFlow Swift 프로젝트
    • Python 3조차 Python을 대체하는 데 오래 걸렸음
    • Python은 대화형 인터프리터 덕분에 반복 개발과 Jupyter Notebook에서 강력함
      CircuitPython도 임베디드 프로토타이핑에 유용했음. Swift는 이런 영역을 제대로 잡지 못했음
      게다가 Swift가 Linux에 온 건 2016년, Windows는 2020년, FreeBSD는 2025년에야 가능해졌음
      2010년대 중반엔 Go, Julia, Rust, TypeScript, Solidity 등 새 언어가 쏟아져서 다들 하나둘만 배울 여유가 있었음
  • Swift가 스택 전층을 아우르는 언어가 되길 바랐지만, 현실은 그렇지 않음
    Apple이 기회를 낭비한 느낌임

    • 나는 실제로 Swift로 스택 전층을 다루고 있음
      예를 들어 ClearSurgery는 리눅스에서 실시간 컴포넌트까지 전부 Swift로 작성되어 있음
  • 지난주에 xv6-riscv 운영체제를 Zig, Nim, LISP, Swift로 포팅했음
    임베디드 Swift의 발전 덕분에 생산성이 높은 언어로 느껴졌음. 메모리 접근을 감싸는 추상화도 깔끔했음
    하지만 컴파일 속도가 너무 느려서 결국 Nim으로 집중하게 됨

    • Nim은 오랜만에 들어보는 이름인데, 왜 그걸 선택했는지 궁금함
    • 혹시 McCarthy LISP를 말하는 건지 물어봄
  • Swift의 컴파일 속도 개선이 언급되지 않아 아쉬움
    Rust보다 느린 컴파일은 개발 경험을 크게 떨어뜨림

    • 나도 최근 Swift 프로젝트를 해봤는데, 의존성이 많을수록 컴파일이 너무 느려서 놀랐음
      Go의 빠른 빌드에 익숙하다면 Swift는 정말 반복 개발이 고통스러움. 언어 자체는 훌륭하지만 피드백 루프가 너무 느림
  • Swift 6.3에서 Android용 공식 SDK가 처음 포함되었음

    • Windows와 Linux용도 있는지 궁금함
      Windows는 5년 전 블로그 글,
      Linux는 GNOME용 가이드가 있음
      예전 OpenSTEP처럼 한 번의 개발로 여러 플랫폼에 배포할 수 있다면 좋겠음
    • 서버용 Swift보다도 덜 쓰일 것 같음
  • noncopyable 타입 개선이 이번 릴리스의 가장 과소평가된 부분임
    이제 Swift에서 고유 소유권 모델링이 훨씬 현실적으로 가능해짐

  • Swift 6.3의 @c 속성으로 Swift 함수를 C 코드에 노출할 수 있게 되었음
    그런데 왜 이렇게 늦게 추가된 건지 의문임. C++ 상호운용을 먼저 넣은 건 이상한 우선순위 같음

    • 사실 예전엔 밑줄 속성으로 이미 존재했음
    • C++ 상호운용은 Apple이 기존 저수준 코드베이스 흡수를 위해 중요했음
      반면 Swift를 C로 내보내면 FFI 스파게티가 생기고, enum·소유권·null 처리 등에서 ABI 버그가 생기기 쉬움
      특히 클로저가 섞이면 호출 규약이 어긋나서 디버깅에 하루를 날릴 수도 있음
    • ObjC로 내보내는 기능이 이미 있었기 때문에 우선순위가 낮았음
    • 예전부터 실험적으로 써봤는데 이제 공식화된 것임
  • 예전에 Swift로 C 프로그램용 dylib을 만들 때 @cdecl을 써야 했는데, 이제 공식 지원이라 반가움

  • 마케팅 외의 실제 변경사항은 CHANGELOG
    Swift Evolution 제안 목록에서 볼 수 있음
    6.3은 주로 통합 작업 중심의 릴리스였음 — stdlib, C/C++, swift-java 상호운용, 빌드 시스템 등
    SPM이 Xcode 기능을 점점 흡수 중이며, 새로운 swift-build 엔진과 prebuilt 모듈도 실험 중임
    하지만 SPM과 Xcode의 상호작용은 여전히 불안정하고, 내부 복잡성이 커지고 있음
    언어 자체의 진보는 조용하지만, 수명 제어와 동시성 색상화 등 깊은 구조 작업이 진행 중임
    여러 OS·디바이스·CI 환경이 얽혀 있어서, Swift 개발자는 항상 변화 속에서 균형을 잡아야 하는 상황

    • Swift 6.4에서는 swift-build가 기본이 될 예정임
      공식 포럼 글에 따르면,
      이미 Xcode가 내부적으로 사용 중이지만 성능 문제가 심각
      관련 토론도 있음.
      SPM과 Xcode가 같은 엔진을 쓰면 개선될 수도 있지만, 큰 기대는 하지 않음
  • 최신 Swift 버전에서 툴체인이 어떤지 궁금함. Swift Lint와 Swift Format이 지원되는지 알고 싶음
    현대 언어라면 내장 포매터와 권장 린트 규칙이 있어야 함. 언어만이 아니라 생태계 전체가 중요함

    • 이제 두 도구 모두 기본 포함됨. 외부 의존성 없이 swift formatswift format lint로 바로 사용 가능함