10P by neo 3달전 | favorite | 댓글 2개
  • Pkl(Pickle로 발음함)은 설정을 생성하기 위한 프로그래밍 언어로, 애플이 내부에서 사용하던 것을 오픈소스화 하여 첫 릴리스를 발표
    • "Configuration that is Programmable, Scalable, and Safe"

  • JSON, YAML, Property Lists와 같은 정적 언어들은 복잡성이 증가할 때 한계가 있음
  • Pkl은 정적 언어와 범용 프로그래밍 언어 사이의 조화를 목표로 함

Pkl 퀵 투어

  • 개발자에게 친숙한 문법과 쉬운 학습을 위해 클래스, 함수, 루프, 타입 주석 등의 기능을 포함
  • Pkl 파일은 설정 스키마를 정의하고, 다른 설정 데이터를 정의하는 데 사용됨
  • Pkl 프로그램은 YAML, JSON, XML 등의 일반적인 형식으로 쉽게 렌더링될 수 있음

내장된 유효성 검사

  • 데이터는 유효해야 하며, Pkl에서는 타입 주석을 사용하여 유효성을 달성함.
  • 타입 주석은 제약 조건을 정의할 수 있으며, 실패하는 제약은 평가 오류를 발생시킴.

패키지 공유

  • Pkl은 패키지를 게시하고 프로젝트에서 의존성으로 가져올 수 있는 기능을 제공함
  • GitHub 릴리스로 패키지를 쉽게 생성 및 게시할 수 있으며, 프로젝트를 통해 의존성을 관리할 수 있음

언어 바인딩

  • Pkl은 텍스트 출력으로 구성을 생성할 수 있으며, 다른 언어로 라이브러리로 내장될 수 있음.
  • Pkl 스키마는 대상 언어의 클래스/구조체로 생성될 수 있으며, Swift, Go, Java, Kotlin 등을 지원함

편집기 지원

  • Pkl 작성 경험을 최상으로 만드는 것을 목표로 함
  • IntelliJ 플러그인을 포함하여 JetBrains 편집기를 위한 풍부한 지원을 제공함
  • 자동 완성, 탐색, 유효성 검사 등의 기능을 제공하며, Language Server Protocol을 지원할 계획임

다음 단계

  • Pkl에 대한 자세한 가이드, 언어 참조, GitHub Discussions를 통한 커뮤니케이션을 제안함
  • Pkl 사용 예제를 위한 샘플 저장소와 CLI 다운로드, 편집기 플러그인 설치를 권장

GN⁺의 의견:

  • Pkl은 설정 관리의 복잡성을 해결하기 위해 만들어진 새로운 프로그래밍 언어로, 개발자들에게 유용할 것으로 보임.
  • 내장된 유효성 검사와 패키지 공유 기능은 코드의 재사용성과 유지 보수성을 향상시킬 수 있음.
  • 다양한 언어로의 바인딩과 편집기 지원은 Pkl을 더 많은 개발 환경에 적용할 수 있게 하여, 개발자들이 보다 쉽게 설정 관리를 할 수 있도록 도와줄 것임.

혹시 했는데 Go 바인드가 있네요. 애플도 고랭을 많이 사용하는것 같습니다.
apple/pkl-go: Pkl bindings for the Go programming language

Hacker News 의견
  • 해커뉴스 댓글 요약:
    • 25년 전 대부분의 프로그램은 GUI를 통한 설정 기능과 도움말을 제공했음. 설정은 ini 파일이나 윈도우 레지스트리에 저장되었으며, 수동으로도 편집 가능했음. 현재는 87MB 크기의 바이너리 형태의 프로그래밍 언어를 사용하여 설정 파일을 생성해야 하며, 이 언어 자체를 실행하기 위해서도 설정 파일을 수동으로 만들어야 함. 이러한 상황에서 500GB 프레임워크가 필요하게 될 것 같은데, 이는 설정 파일을 생성하는 프로그래밍 언어를 위한 것임. 현대 개발자들이 문제를 만드는 데에 종사하는 것처럼 보임.
    • Pkl은 애플에서 내부적으로 사용되던 최고의 도구 중 하나였으며, 이제 오픈소스로 공개되어 기쁨. 한 팀은 여러 kloc의 k8s 설정을 pkl로 성공적으로 마이그레이션했으며, pkl을 사용하여 두 가지 모니터링 도구를 위한 설정, 정적인 문서 사이트를 생성하고 모두 연결하는 경고 정의를 작성함. 이 도구를 추천하고 싶으며, 다시 사용할 수 있게 되어 흥분됨.
    • Pkl은 GraalVM Truffle 프레임워크를 사용하여 구축되었으며, Futamura 투영을 사용한 런타임 컴파일을 지원함. 애플과 함께 이 작업을 오랫동안 진행해왔으며, 드디어 소스 코드를 볼 수 있게 되어 매우 기쁨. (GraalVM 개발자의 말)
    • HTTP 리소스를 가져오고 파일 시스템에서 파일을 읽는 기능과 튜링 완전성은 설정 언어에서 예상치 못한 기능임. 이러한 복잡성이 정당화되는지 궁금함.
    • 문서를 조금 읽어본 결과, 스키마 정의와 최소값 전달자로서의 언어를 만들고자 하는 아이디어에 너무 몰두한 것 같음. 과도한 사용으로 인한 예상치 못한 실패 모드가 우려됨. 그러나 이것이 핵심 기능일 수도 있음: pkl을 소프트웨어에 추가하는 모든 사람은 결과적으로 생성될 설정 괴물에 참여하게 됨. 구조가 없는 혼란보다는 통일된 시스템이 덜 나쁠 것이라는 가정에 기반함.
    • IntelliJ, Visual Studio Code, Neovim용 플러그인과 확장 기능을 제공하며, 곧 Language Server Protocol 지원이 추가될 예정임. 왜 LSP를 먼저(또는 유일하게) 구현하지 않았는지 이해할 수 없음. 모든 편집기가 LSP를 내장 지원하므로 별도의 구현이 필요하지 않았을 것임.
    • 설정 언어에 대해 오랫동안 고민한 결과, 스키마와의 사랑/증오 관계를 겪은 후, 설정에서 풍부한 타입을 원하지 않는다는 결론에 도달함. 정적 타입의 프로그래밍 언어를 사용하며, 설정 언어에서는 문자열, 배열, 해시맵만을 타입으로 사용하고 모든 타입 검증을 파싱 단계로 밀어내고 싶음.
    • Cue와 비슷하지만 더 원시적이고, 원칙이 덜하며 Java로 작성되었음.
    • Pkl이 해결하려는 문제를 이해하는 데 어려움을 겪음. 제목을 읽고 나서 Pkl이 TOML과 같은 새로운, 더 나은 설정 언어라고 생각했지만, 기사를 읽고 나니 Pkl이 설정을 _생성_하기 위한 언어라는 인상을 받음. Pkl은 설정 파일 자체가 아니라, 설정을 더 표준화된 방식으로 구축하고 재사용하는 데 도움이 되는 추상화된 도구로 보임. 예를 들어, 여러 프로젝트에서 공유하거나 반복하고자 하는 Terraform이나 Cloudformation 설정이 있을 때, 가장 쉬운 방법은 다른 프로젝트에서 복사하여 붙여넣고, 몇 줄을 변경하여 프로젝트에 맞게 수정하는 것임. Pkl은 이러한 문제를 해결하는 데 도움이 되는 것인지, 아니면 다른 것을 놓치고 있는 것인지 궁금함.