Rust 언어는 좋아하지만, Rust의 의존성 문제는 싫음. C++의 의존성 관리가 더 나음. C++에서는 의존성을 스스로 통제할 수 있지만, Rust에서는 너무 많은 의존성이 생겨 포기하게 됨. 보안 측면에서도 내가 무엇을 배포하는지 알 수 없음. Rust는 ABI 호환성이 없고 공유 라이브러리 문화도 부족함. 이는 OS 패키지 배포 모델을 파괴함.
터미널 API는 안정적이지 않음. TIOCGWINSZ ioctl은 표준화되지 않았고, POSIX에 tcgetwinsize() 함수가 추가된 것은 2024년임. Windows 쪽은 더 복잡함.
2006년에 만든 웹 앱을 부활시킴. 새로운 CI/CD 기술을 배우기 위해 앱의 배포 과정을 과도하게 설계함. PHP와 MySQL을 사용했으며, 대부분의 코드를 직접 작성함. 19년 된 앱을 부활시키는 데 한 시간밖에 걸리지 않음. 반면, 현재 직장에서 사용하는 Spring Boot 앱은 의존성 문제로 업데이트가 어려움.
NodeJS는 경력에 큰 영향을 미쳤지만, NPM은 많은 문제를 일으킴. 새로운 의존성을 추가하려고 하면 다른 의존성과 충돌함. Expo의 경우 기본 React Native 프로젝트가 Android에서 빌드되지 않는 문제가 있음. 대규모 프로젝트도 비기능적인 템플릿을 배포할 수 있다는 점에서 자신감을 얻음.
Rust 생태계는 Go와 비교했을 때 의존성이 많음. Go는 인터페이스가 암시적으로 만족되므로 추가적인 의존성이 필요 없음.
라이브러리의 추상화는 숨겨진 비용이 있음. 패키지가 디자인을 변경하면 불안정성이 생김. 간단한 것이 가장 오래 살아남음. Rust뿐만 아니라 다른 언어에서도 비슷한 문제를 봄.
ChatGPT나 Cursor가 의존성 없는 구현을 빠르게 만들어주는 것이 더 빠름. 많은 SaaS/3rd party 서비스 의존성이 이미 해결된 문제임.
Flask와 Bottle은 비슷한 기능을 가졌지만, Flask가 더 인기를 끌었음. Bottle은 단일 파일로 의존성이 없어 프로젝트에 쉽게 복사할 수 있었음. 그러나 현대적인 Python 관행을 따라가지 못해 구식으로 느껴짐.
스스로 솔루션을 개발할 수 있는 능력 있는 엔지니어가 필요함. 기존 라이브러리보다 더 나은 솔루션을 쉽게 만들 수 있음. 프로젝트에서 마크다운 변형을 위한 파서를 작성했지만, 팀원들이 유지보수를 이유로 사용하지 않음.
하나의 함수만 사용하면서 수백 개의 함수를 컴파일하는 것은 문제가 있음. 3rd party 의존성을 업데이트하는 프로젝트에서 수학 라이브러리의 한 메서드만 사용하고 있었음. 엔지니어에게 Wikipedia 페이지를 참고하여 직접 메서드를 작성하도록 권장함. 문제는 3rd party 의존성을 사용하는 것이 아니라, 라이브러리의 작은 부분만 가져오는 개념이 필요함. "마이크로프레임워크"가 해결책이 될 수 있음.
Hacker News 의견
Rust 언어는 좋아하지만, Rust의 의존성 문제는 싫음. C++의 의존성 관리가 더 나음. C++에서는 의존성을 스스로 통제할 수 있지만, Rust에서는 너무 많은 의존성이 생겨 포기하게 됨. 보안 측면에서도 내가 무엇을 배포하는지 알 수 없음. Rust는 ABI 호환성이 없고 공유 라이브러리 문화도 부족함. 이는 OS 패키지 배포 모델을 파괴함.
터미널 API는 안정적이지 않음. TIOCGWINSZ ioctl은 표준화되지 않았고, POSIX에 tcgetwinsize() 함수가 추가된 것은 2024년임. Windows 쪽은 더 복잡함.
2006년에 만든 웹 앱을 부활시킴. 새로운 CI/CD 기술을 배우기 위해 앱의 배포 과정을 과도하게 설계함. PHP와 MySQL을 사용했으며, 대부분의 코드를 직접 작성함. 19년 된 앱을 부활시키는 데 한 시간밖에 걸리지 않음. 반면, 현재 직장에서 사용하는 Spring Boot 앱은 의존성 문제로 업데이트가 어려움.
NodeJS는 경력에 큰 영향을 미쳤지만, NPM은 많은 문제를 일으킴. 새로운 의존성을 추가하려고 하면 다른 의존성과 충돌함. Expo의 경우 기본 React Native 프로젝트가 Android에서 빌드되지 않는 문제가 있음. 대규모 프로젝트도 비기능적인 템플릿을 배포할 수 있다는 점에서 자신감을 얻음.
Rust 생태계는 Go와 비교했을 때 의존성이 많음. Go는 인터페이스가 암시적으로 만족되므로 추가적인 의존성이 필요 없음.
라이브러리의 추상화는 숨겨진 비용이 있음. 패키지가 디자인을 변경하면 불안정성이 생김. 간단한 것이 가장 오래 살아남음. Rust뿐만 아니라 다른 언어에서도 비슷한 문제를 봄.
ChatGPT나 Cursor가 의존성 없는 구현을 빠르게 만들어주는 것이 더 빠름. 많은 SaaS/3rd party 서비스 의존성이 이미 해결된 문제임.
Flask와 Bottle은 비슷한 기능을 가졌지만, Flask가 더 인기를 끌었음. Bottle은 단일 파일로 의존성이 없어 프로젝트에 쉽게 복사할 수 있었음. 그러나 현대적인 Python 관행을 따라가지 못해 구식으로 느껴짐.
스스로 솔루션을 개발할 수 있는 능력 있는 엔지니어가 필요함. 기존 라이브러리보다 더 나은 솔루션을 쉽게 만들 수 있음. 프로젝트에서 마크다운 변형을 위한 파서를 작성했지만, 팀원들이 유지보수를 이유로 사용하지 않음.
하나의 함수만 사용하면서 수백 개의 함수를 컴파일하는 것은 문제가 있음. 3rd party 의존성을 업데이트하는 프로젝트에서 수학 라이브러리의 한 메서드만 사용하고 있었음. 엔지니어에게 Wikipedia 페이지를 참고하여 직접 메서드를 작성하도록 권장함. 문제는 3rd party 의존성을 사용하는 것이 아니라, 라이브러리의 작은 부분만 가져오는 개념이 필요함. "마이크로프레임워크"가 해결책이 될 수 있음.