▲

OxCaml - OCaml 프로그래밍 언어를 위한 확장 셋

 (oxcaml.org)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • OxCaml은 OCaml에 성능 지향적인 기능을 추가하는 확장 셋임
  • Jane Street의 프로덕션 컴파일러이자 OCaml의 미래 기능 실험실 역할을 함
  • 안전성, 편의성, 예측 가능성을 중시하여 성능 제어 확대를 지향함
  • Fearless concurrency, 레이아웃 제어, 할당 제어 등 다양한 영역의 기능을 제공함
  • 오픈소스로 제공되어 실험적 사용자와 연구자가 자유롭게 테스트 및 의견 제공 가능함

OxCaml 소개

OxCaml이란 무엇인가

  • OxCaml은 OCaml 프로그래밍 언어에 대한 빠르게 발전하는 확장 기능 집합임
  • 이는 Jane Street의 실무용 컴파일러이자, OCaml의 성능 중심 프로그래밍 강화를 위한 실험적 플랫폼임
  • 목표는 이 확장 기능들을 장기적으로 공식 OCaml에 기여하는 것임

OxCaml의 주요 설계 목표

  • 프로그램 동작의 성능 결정적 요소를 안전하고, 편리하며, 예측 가능하게 제어할 수 있는 환경 제공 목적임
  • 이 제어는 정말 필요할 때에만 선택적으로 제공됨
  • 모든 것은 OCaml 환경 내에서 구현됨

구체적 설계 방안

  • 안전성: 프로그래머 생산성과 코드의 정확성 보장을 위해 언어적 안전성 강화. 광범위한 비안전 언어는 사용 난이도가 높음

  • 편의성: 프로그래밍 복잡성을 늘리지 않고, 타입 추론의 이점을 유지하며 제어력을 부여함

  • 예측 가능성: 핵심 성능 특성을 타입 시스템 수준에서 명시적으로 드러내, 코드 성능 추론을 용이하게 함

  • 이 확장들은 필요한 부분에서만 적용되는 pay-as-you-go 방식임. 즉, 확장 기능을 사용하지 않으면 기존 OCaml의 단순성과 패턴을 그대로 유지할 수 있음

  • OxCaml은 모든 OCaml 프로그램과 호환되며, 내부적으로는 진화한 OCaml을 지향함. 기존 OCaml이 가진 안전성, 사용 편의성, 생산성을 유지함

OxCaml 확장 기능 소개

Fearless concurrency

  • 올바른 동시성 프로그래밍은 매우 어렵다는 점을 해결하기 위해, OxCaml은 타입 시스템 확장으로 데이터 레이스를 정적으로 차단함

레이아웃(Layouts)

  • 프로그래머가 메모리 내 데이터 레이아웃을 명시적으로 지정할 수 있음
  • 최신 하드웨어의 SIMD 프로세서 확장에 대한 네이티브 접근도 제공함

할당 제어

  • 메모리 할당을 세밀하게 제어하는 도구를 제공하여, 가비지 컬렉션(GC) 부담을 감소시키고, 캐시 효율성 및 프로그램 결정성을 향상함

생활 품질 개선(Quality of life)

  • 시스템 프로그래밍 이외에도 개별 업무에서 도움이 되었던 기능을 제공

    • Polymorphic parameters
    • Include functor
    • Labeled tuples
    • Immutable arrays

OxCaml의 활용 및 적용

  • OxCaml은 오픈소스로 공개되어 연구자, 실험 사용자, 개발자 모두가 테스트와 피드백을 통해 기여할 수 있음

  • 단, OxCaml의 확장 기능은 안정성 및 하위호환성을 확약하지 않음 (기존 OCaml 프로그램과는 하위호환 보장함)

  • 표준 OCaml 도구들을 OxCaml에 맞게 수정한 버전이 제공됨

    • 패키지 매니지먼트: dune 및 opam과 호환
    • 에디터 통합: LSP-server 지원
    • 소스 코드 포매팅 및 문서 생성 기능 탑재

  • Jane Street에서 공개한 여러 라이브러리와 도구들이 두 가지 형태로 제공됨

    • Upstream OCaml용: OxCaml 확장이 제거된 버전
    • OxCaml 전용: 확장 기능을 활용한 버전

  • 일부 확장 기능은 제거가 불가하여 해당 라이브러리는 OxCaml에서만 사용 가능함. 필요한 확장이 공식 OCaml에 통합되면, OCaml 호환 버전도 공개 예정임

▲
GN⁺ 1일전  [-]
Hacker News 의견

  • Janet Street 팀이 만든 이 프로젝트와 관련해서, 이분들이 출연한 팟캐스트 에피소드에서 OCaml로 작업할 때의 성능 고려 사항에 대해 흥미로운 논의가 있었다고 소개하고 싶음
    GC 언어를 극한 저지연 환경에 적용할 때의 고민이 계속됨
    예를 들어, GC pause가 고빈도 트레이딩의 중간에 발생한다면 심각한 문제가 될 수 있는 상황
    팟캐스트 링크 공유

    • 실제로 Twitter에서 Ron Minsky에게 저지연 애플리케이션에 Rust를 쓰지 않는 이유에 대해 직접 질문한 경험 공유
      Ron의 답변에서 Rust가 훌륭함을 인정하는 동시에, 전체 코드를 하나의 언어로 유지하는 것의 가치에 집중
      타입, 툴, 라이브러리, 관용구 등 공유 가능성 및 프로젝트 간 이동의 용이성이 큼
      또한 OCaml 내부적으로 Rust의 주요 이점을 잘 통합하여 점진적 활용이 가능하도록 발전 중인 사항
      Rust의 단점으로는 긴 컴파일 시간, 복잡한 타입 체계, 비동기/await 처리에 대한 불만 등을 언급
      무엇보다도 광범위한 작업 환경에 적합한 단일 언어 도구를 원하는 입장 강조
      해당 트윗 링크

    • GC 언어 자체가 핵심 문제가 아니라 오히려 모든 GC 언어를 하나로 취급하는 관점에 문제가 있다고 강조
      정말 중요한 문제는 GC 언어가 스택 및 값 타입의 명시적 조작을 지원하지 않을 때
      GC 언어의 생산성과 함께 시스템 레벨 코딩을 위한 세밀한 옵션을 원한다면 Cedar, Oberon 계열, Modula-3, D, Nim, Eiffel, C#, F#, Swift, Go와 같은 대안 언급

    • GC를 사용하는 런타임 환경에 대한 일반적 얘기로, GC pause 최소화를 위해 JVM의 병렬 수집 알고리즘 등 활용 가능
      단, 이 방법은 획일적 보장이 없으므로 시스템 RAM 오버 프로비저닝이 추가적으로 필요한 상황
      더 나아가 서버를 의도적으로 오버 프로비저닝해서 일부 서버가 잠시 풀에서 빠질 수 있게 "오프라인 GC"를 처리하는 방법도 있음
      이러한 방식은 요청 라우터 및 서버 간 협업이 필요해서, 서버 확장에 충분한 예산이 있는 경우에만 유의미
      JVM 병렬 GC 설명

    • GC 컴팩션 이슈로 여러 시스템이 고생한 경험 공유
      트레이딩 시스템에서는 일반적으로 시동 후에는 할당을 최소화한다는 정책을 많이 씀
      JS에는 "Zero"라는, 비할당 방식의 유틸리티를 제공하는 라이브러리가 있음

    • 링크를 확인하진 않았지만, 트레이딩처럼 장시작·마감 구간이 있는 환경이라면 장 중에는 GC를 비활성화하고, 마감 후 재시작하는 방법도 가능하겠다는 의견

  • 이번 포크에서 최초로 upstream된 기능은 labeled tuple임을 강조하고 싶음
    OCaml 5.4에서 지원 예정
    업스트림 PR 링크
    관련 토론 링크

    • 이 기능이 다소 사소해 보여도 꽤 기대감이 큼
      해당 기능의 저자가 ML2024에서 발표한 논문과 영상도 정보로 추가하고 싶음
      Youtube 영상
      논문 PDF

    • labeled tuple 예시로 쌍의 순서 실수 방지가 가능한데, 개인적으로는 F#의 익명 레코드가 더 마음에 든다는 의견
      예를 들면, {| product = 6; sum = 5 |}와 같이 필드 순서가 의미 없으니 실수가 없음

    • 이번 포크에서 immutable array도 5.4에 합쳐졌는데, 문법만 약간 다름

    • 익명 labeled struct와 enum이 프로그래밍 언어에서 바라는 상위권 기능임을 강조
      예시로 Rust에서는 labeled와 unlabeled struct를 모두 정의할 수 있지만
      함수 반환형에는 익명 labeled struct를 쓸 수 없다는 아쉬움 표출

      struct Foo(i32, i32);
struct Bar{sum: i32, product: i32}
fn can() -> (i32, i32)
fn cant() -> {sum: i32, product: i32}

  • 이 포크가 SIMD를 지원한다는 사실을 몰랐음
    unboxed type, 명시적 stack 할당 기능, Windows까지 지원된다면 개인적으로 F# 대신 OxCaml이 game dev 등 컨슈머 환경에서 충분히 쓸 만해질 가능성 언급

    • 현재 128-bit SSE/NEON이 작동 중이고 곧 AVX도 지원 예정
      Windows 지원은 막혀있는 건 아니지만 약간의 작업 필요
      개인적으로 OxCaml에서 SIMD 지원을 추가했다는 점 짚고 싶음

  • 새로운 opam switch를 사용하는 이들에게 환경 변수 세팅 팁 공유
    env OCAMLPARAM="alert=-unsafe_multidomain,_," opam install cohttp-lwt-unix
    알림(alert)이 오류로 승격되면 기존 패키지 설치 때 불필요하게 설치가 깨지는 문제 해결
    OCAMLPARAM 환경변수로 해당 alert 비활성화해서 설치 문제 예방 가능

  • Golang을 위한 훌륭한 vscode 플러그인에 익숙하다며, 오캄 환경도 vscode와 통합될 계획이 있는지 궁금함
    vscode와의 통합이 세팅을 매우 간편하게 만들었음

    • OCaml vscode 플러그인 자체가 dune, menhir, reason 같은 새로운 문법 통합을 이미 많이 지원함
      OxCaml 인기도가 오르면 당연히 통합 진전 가능성
      개인적으로는 emacs를 써서 자세하게 말하긴 어렵지만 자연스러운 흐름 예상

  • OcaML의 마이크로 사이즈 버전을 언급하고 싶음
    mlite 프로젝트 링크

  • 이 프로젝트가 공개된 목적이 LLM이 정보를 인덱싱해서 공개모델로 활용하려는 의도 때문일 수 있는지 물음

    • LLM이 일반 OCaml에 대해서조차 너무 부족하고 데이터량도 적은데, OxCaml은 더욱 자료가 부족해서 그럴 가능성은 전혀 없다고 판단
      이런 목적으로는 자체 문서 MCP를 만드는 게 더 유의미

    • 신호로서의 가치가 충분치 않기 때문에 사실상 의미가 없음
      예를 들어 Gleam 완성에서도 LLM의 성능은 매우 낮으며, 명확한 패턴과 실수 지침을 주더라도 실패
      이 때문에 OxCaml 정보 제공 목적이라기엔 신호 약함

  • OxCaml이 ML 계열 방언의 방언의 확장이라는 점이 재미있다는 관전 포인트
    다음 단계가 어떤 모습일지 기대감 있음

    • 기존 언어에 계속 기능 붙이는 사람들과, 애초에 새 언어를 만드는 사람들 중 누가 더 문제인지 자문해본 적 있음
      본인은 후자에 속하지만, 프로그래머는 도구를 있는 그대로 두질 못하는 유전자적 특성이 있다고 생각

    • 혹시 F#도 소개해볼 수 있겠냐는 농담 섞인 권유

  • 이 프로젝트가 "oxidized"라는 명칭을 쓰는 이유가 Rust(예: fearless concurrency, GC 회피 등)의 기능 목표와 관련한 것인지, Rust를 실제로 사용하기 때문은 아니라는 점 확인
    다소 혼동될 수 있는 네이밍임을 피력

    • 실제로 Rust라는 이름은 녹이 아닌 곰팡이 'Rust'에서 온 거라는 작은 아이러니 포인트 짚고 싶음

    • Jane Street가 'Oxidizing OCaml'이라는 블로그 시리즈를 오래전부터 운영해온 사실 공유

    • 실제로 "Oxidizing OCaml with Modal Memory Management"라는 논문의 제목에도 이 용어가 사용됐으며, 논문 내에서 'oxidize'란 단어가 명확히 정의되거나 인용된 적은 없음
      이상하기도 하지만 꽤 중독성 있는 이름이라는 인상

    • Rust 쪽이 커스텀 트레이싱 GC(일반적인 그래프 구조 다루면서도 최대 성능 추구 가능)와의 통합에서 이 프로젝트가 Rust와 기능 동등성을 확보하기 전까지 더 실용적으로 쓰일 것이라는 예측
      그렇지 않으면 단지 OxCaml 관련 코드베이스가 많아서 유지한다는 목적 정도로만 느껴진다고 평가

답변달기