GN⁺: Rust가 그만한 가치가 있었나?

• 저자 Jarrod Overson이 주로 WebAssembly를 위해 Rust를 3년 동안 사용한 경험을 공유.
• 그는 Rust를 사용하여 WebAssembly를 핵심 모듈 시스템으로 사용하는 애플리케이션 프레임워크 및 런타임인 Wick를 구축.
• Rust의 테스트 주도 개발 방식은 더 많은 유지 관리를 덜 노력으로 가능하게 하며, 광범위한 테스트의 필요성을 줄임.
• 저자는 Rust에서 프로그래밍하면 다른 언어에서의 코딩 기술이 향상된다는 것을 발견.
• Clippy, Rust의 린터,는 성능, 가독성, 불필요한 간접성을 향상시키는 광범위한 규칙을 받아들임.
• 그러나 저자는 Rust의 라이브러리와 도구에서 특정 사용 사례를 종종 다루지 않는 부분을 지적.
• 그는 특정 제한 때문에 crates.io, Rust의 패키지 레지스트리에 패키지를 게시하는 데 어려움을 비판.
• 저자는 또한 Rust의 async-iness를 비판하며, 이는 종종 해결하기 어려운 오류로 이어지는 사후 생각으로 설명.
• Rust의 풍부한 타입 시스템 때문에 리팩토링이 어려울 수 있음.
• 단점에도 불구하고 저자는 Rust의 다양성과 견고성을 칭찬.
• 저자는 빠른 반복이 필요한 프로젝트에는 Rust가 적합하지 않을 수 있지만, 알려진 범위의 프로젝트나 더 많은 선불 비용을 감수할 수 있는 프로젝트에는 고려할 가치가 있다고 결론.

[neo]

Hacker News 의견

• 일부 사용자들은 Rust가 비생산적이고 제한적이라고 느껴 Zig와 같은 다른 언어를 선호하여 코딩에 더 집중하게 됩니다.
• crates.io에서 네임스페이스가 부족한 것이 비판의 대상이며, 이로 인해 누구나 전역 패키지 이름을 주장할 수 있어 문제가 발생할 가능성이 있습니다.
• 일부 사용자들은 Rust의 광범위한 라이브러리와 우수한 문서화 시스템을 높이 평가합니다.
• 프로젝트에 대한 전역 lint 설정의 부재에 대한 우려가 있지만, .cargo/config.toml 파일을 사용하는 해결책이 제안되고 있습니다.
• 일부 사용자들은 중요한 저수준 크레이트들이 0.x 버전에서 멈춰있는 상황에 대해 불만을 표현합니다.
• 백 레퍼런스의 언어 수준 문제가 강조되며, 정적 분석 솔루션에 대한 요구가 있습니다.
• 일부 사용자들은 Rust 컴파일러를 유용하게 사용하며, 그 오류 메시지를 칭찬합니다.
• Rust에서 테스팅의 필요성에 대한 논쟁이 있으며, 일부는 컴파일이 되면 아마도 정확할 것이라고 주장하는 반면, 다른 일부는 비즈니스 로직은 여전히 테스트되어야 한다고 주장합니다.
• 일부 사용자들은 Rust 사용이 불편하다고 느끼지만 전문적인 이유로 Rust를 배우고 있습니다.
• 일부 사용자들은 프로그래머가 컴파일러가 하는 모든 것을 완전히 통제하고 완전히 인식해야 한다는 생각을 깨뜨리는 Rust를 높이 평가합니다.
• Rust에서 async의 사용에 대한 논쟁이 있으며, 일부 사용자들은 이를 불만의 원인으로 보는 반면, 다른 일부는 모든 것에 사용되어야 한다고 믿습니다.