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 관련 코드베이스가 많아서 유지한다는 목적 정도로만 느껴진다고 평가