▲

GN⁺: 러스트 재작성

 (josephg.com)
1P by neo 2달전 | favorite | 댓글 1개

Rust 재작성

  • Rust 프로그래밍 언어는 첫 번째 세대 제품처럼 느껴짐
  • Rust의 초기 매력: 대수적 타입, 메모리 안전성, 성능 저하 없음, 현대적 패키지 관리자
  • 4년간 사용 후, Rust는 항상 완벽하지 않음
  • 언어의 발전이 매우 느려짐
  • 많은 불안정한 기능이 안정적인 Rust에 포함되지 않음

환상적인 언어

  • Rust 컴파일러를 포크하고 새로운 "seph" 에디션을 만들고 싶음
  • Rust의 기존 기능을 유지하면서 새로운 기능 추가 가능

함수 트레이트 (효과)

  • Rust는 구조체에 트레이트를 정의하지만 함수에도 트레이트를 정의할 필요가 있음
  • 함수의 다양한 특성을 나타낼 수 있음
    • 함수가 패닉을 일으키는지 여부
    • 고정된 스택 크기를 가지는지 여부
    • 함수가 끝까지 실행되는지 아니면 중간에 대기하는지 여부
    • 함수가 순수한지 여부
    • 함수가 안전하지 않은 코드를 실행하는지 여부
    • 함수가 종료를 보장하는지 여부

컴파일 타임 기능

  • 많은 Rust 프로젝트가 많은 서드파티 크레이트를 사용함
  • 이러한 크레이트는 공급망 위험을 증가시킴
  • 보안에 민감한 함수 호출을 명시적으로 허용하도록 하는 기능 추가 제안
  • fs_write와 같은 기능을 호출하려면 명시적으로 허용해야 함

Pin, Move 및 구조체 대여

  • Pin은 Rust의 대여 검사기 문제를 해결하기 위한 복잡한 해킹
  • Pin 대신 Move 마커 트레이트를 사용하는 것이 더 합리적
  • 구조체 필드를 대여 상태로 표시할 수 있는 구문 추가 제안
  • Move 마커 트레이트와 Mover 트레이트 도입 제안

컴파일 타임

  • Zig의 comptime 기능을 도입하여 Rust 매크로 언어를 대체
  • 컴파일 타임에 코드를 실행할 수 있는 작은 인터프리터 추가
  • Rust의 매크로 언어 대신 Rust 자체를 사용

작은 수정 사항

  • impl<T: Copy> for Range<T> 수정
  • 연관 타입을 가진 derive 수정
  • if-let 표현식에서 논리 AND 지원
  • 원시 포인터의 사용성을 개선
  • 모든 내장 컬렉션 타입에 Allocator 인자를 추가

마무리 생각

  • 비동기 기능도 개선이 필요하지만 별도의 포스트가 필요함
  • 대부분의 변경 사항은 기존 Rust와 호환되지 않음
  • 새로운 Rust 에디션이 필요할 수 있음
  • GitHub RFC 프로세스에 지치지 않고 직접 컴파일러를 포크하는 것을 고려 중

GN⁺의 정리

  • Rust는 초기 매력에도 불구하고 완벽하지 않음
  • 언어 발전이 느려지고 많은 불안정한 기능이 안정적인 Rust에 포함되지 않음
  • 함수 트레이트, 컴파일 타임 기능, Pin 및 Move 개선 등 다양한 제안이 있음
  • 이러한 제안은 Rust의 사용성을 크게 개선할 수 있음
  • 비슷한 기능을 가진 다른 언어로는 Zig가 있음
▲
neo 2달전  [-]
Hacker News 의견

  • Rust RFC 프로세스에 대한 의견

    • Rust 핵심 팀이 새로운 기능 추가를 어렵게 만드는 것은 언어의 일관성과 예측 가능성을 유지하기 위해 옳은 결정임
    • Swift의 경우, 많은 새로운 기능 도입으로 인해 복잡해져서 결국 Swift를 포기하게 되었음
    • Rust는 가능한 한 간결하게 유지하는 것이 중요함

  • Rust의 의존성 문제

    • Cargo-watch crate의 예를 들어, 간단한 파일 감시 앱이지만 의존성으로 인해 코드 라인이 400만 줄에 달함

  • Rust의 현재 상태

    • Rust는 이제 "광범위한 채택을 위한 작업" 단계에 있음
    • 느린 기능 개발은 자연스럽고 건강한 현상이며, 잘못된 설계 선택이 더 큰 해를 끼칠 수 있음
    • Rust의 매력은 새로운 기능보다는 메모리 안전성과 GC가 없는 생산 준비된 언어라는 점에 있음

  • Rust의 재작성에 대한 의견

    • Rust를 Rust로 재작성하는 것은 메타-풍자적 농담으로 보였음

  • Rust의 결정 과정에 대한 불만

    • 느린 결정 과정에 대한 불만이 있지만, 이는 기술적 문제보다는 사람과 시간의 문제임
    • 일부 오래된 기능은 정체되어 있지만, 많은 기능은 안정화되지 않을 예정임

  • Josh Triplett의 댓글

    • 특정 예시가 잘못되었음을 지적하며, 관련 링크를 공유함

  • Rust의 복잡성에 대한 의견

    • Rust는 이미 많은 기능을 가지고 있지만, 더 많은 기능을 요구하는 사람들이 있음
    • Zig는 더 간단하고 빠르며, 커뮤니티의 드라마가 적음

  • Rust의 속도에 대한 의견

    • 프로젝트가 성숙해지면서 기존 기능을 다듬는 데 많은 노력이 필요함
    • 팀 간의 협력이 어려워졌으며, 이를 개선하기 위한 프로젝트 목표가 있음

  • Mutex 개선에 대한 의견

    • Rust의 동기화 원시 기능을 개선하기 위해 많은 노력이 있었음
    • 비동기 함수와 같은 기능이 추가되었으며, 이는 더 복잡한 기능을 구현하기 위한 기반이 됨

  • Rust의 기능 개발 속도에 대한 의견

    • 언어가 너무 빠르게 또는 너무 느리게 발전한다고 불평하는 사람들이 있음
    • 특정 기능은 더디게 진행되지만, 많은 활동이 진행 중임

  • Rust의 기능 설계에 대한 의견

    • 함수 트레이트와 같은 기능은 최근에 큰 설계 탐구가 있었음
    • 컴파일 타임 기능은 언어 수준에서 해결할 수 없으며, WebAssembly와 같은 솔루션이 더 가능성이 있음

  • Rust의 빌림 검사기 문제

    • 자기 참조 구조를 이해하는 것은 매우 어려운 문제임
    • 부분 빌림을 지원하는 방법은 이미 알고 있지만, 이를 타입 시스템에 노출하는 것이 문제임

  • Rust의 컴파일 타임 기능

    • 매크로 규칙을 더 강력하게 만들기 위한 RFC가 작성되었음
    • 프로그램적 구문 분석을 위한 더 많은 작업이 필요함

  • Rust의 불안정한 기능

    • 많은 불안정한 기능이 있으며, 이를 정리하는 것이 필요함

  • Rust의 발전 속도에 대한 의견

    • Mozilla의 이탈로 인해 프로젝트가 느려졌지만, 잘못된 길로 가는 것보다는 나음
답변달기