▲

GN⁺: 직접 제작하는 Build It Yourself 프로그램

 (lucumr.pocoo.org)
2P by neo 1달전 | ★ favorite | 댓글 1개

  • 또 다른 의존성에 대한 생각

    • 의존성에 대한 새로운 관점을 제안함. 의존성의 과도한 사용을 줄이고, 직접 코드를 작성하는 방향으로 전환할 필요가 있음.

  • 의존성 문제

    • "의존성 소모"는 개발자들이 생산성을 위해 설치하는 업데이트, 패치, 감사, 전이적 의존성의 끝없는 반복임.
    • JavaScript와 Rust는 특히 의존성 문제에 취약함. 예를 들어, 새로운 Tokio 프로젝트는 28개의 크레이트를 포함하고, Rocket 프로젝트는 172개로 늘어남.

  • 터미널 크기 문제

    • terminal_size 크레이트는 터미널 크기를 측정하는 간단한 기능을 제공하지만, 여러 추가 크레이트를 필요로 함.
    • 이로 인해 수천 개의 다른 기능을 컴파일해야 하는 상황이 발생함.

  • 의존성의 필요성

    • 플랫폼 추상화 라이브러리 위에 구축되어 있어, 코드 중복을 피하고 컴파일 시간을 줄이기 위해 업데이트가 필요함.
    • 보안 문제의 주요 원인이 되는 경우가 많음.

  • 코드의 목표

    • 코드가 업데이트가 필요 없는 방식으로 작성되어야 함. Rust 생태계에서는 안정적인 코드가 불이익을 받음.

  • 직접 코드 작성의 장점

    • 직접 코드를 작성하면 새로운 크레이트가 필요 없고, 유지보수의 필요성이 줄어듦.
    • ChatGPT와 같은 도구를 사용하여 의존성 없는 구현을 빠르게 작성할 수 있음.

  • 오픈 소스와 기업 문화

    • 기업의 코드 리뷰 문화가 오픈 소스 소프트웨어에 영향을 미침.
    • 새로운 라이브러리를 사용하는 것이 긍정적으로 여겨짐.

  • 새로운 관점의 필요성

    • 작은 기능을 직접 작성하는 엔지니어를 칭찬해야 함.
    • 큰 크레이트 그래프에 대해 의심을 가져야 함.

  • 중요한 라이브러리

    • 복잡한 문제를 해결하는 중요한 라이브러리도 존재함. 예를 들어, 그래픽 라이브러리나 프로토콜 구현 등.

  • 직접 구축의 중요성

    • 적절할 때 직접 구축하는 것을 축하해야 함.
    • 의존성이 적거나 없는 오픈 소스 라이브러리를 구축하는 라이브러리 저자에게 공로를 인정해야 함.

  • 결론

    • 의존성을 줄이고 직접 코드를 작성하는 방향으로 전환해야 함.
    • minijinja는 의존성을 최소화한 예시로, serde 하나만을 의존함.
▲
neo 1달전  [-]
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 의존성을 사용하는 것이 아니라, 라이브러리의 작은 부분만 가져오는 개념이 필요함. "마이크로프레임워크"가 해결책이 될 수 있음.

답변달기