▲

OCaml을 사랑하는 이유 (2023)

 (mccd.space)
1P by GN⁺ 21시간전 | ★ favorite | 댓글 1개
  • 함수형 프로그래밍과 정적 보장을 중시하는 개발자가 여러 언어를 경험한 끝에 OCaml의 균형 잡힌 설계를 높이 평가
  • Haskell의 복잡한 타입 시스템과 느린 컴파일 속도에 비해, OCaml은 단순성과 실용성을 함께 제공
  • Go의 빠른 컴파일과 간결한 런타임을 닮았지만, 함수형 언어의 패턴 매칭·합타입 같은 강점을 유지
  • 빠른 빌드, 정적 바이너리, 풍부한 문서화 도구(odig, utop) 등으로 생산성과 접근성이 높음
  • 단순성과 표현력의 균형, 그리고 세련된 언어 설계가 OCaml의 가장 큰 매력으로 제시됨

프로그래밍 언어 경험과 비교

  • 다양한 언어로 아마추어 및 전문 소프트웨어를 개발한 경험을 통해 좋은 언어의 특징을 정리
    • 빠른 컴파일 속도, 단순한 런타임, 강한 정적 보장, 함수형 구성요소, 좋은 성능, 문서화 품질을 중요 요소로 제시
  • Haskell은 함수형 프로그래밍의 사고방식을 익히게 했지만, 복잡한 문법과 느린 컴파일이 문제로 지적됨
    • 커뮤니티의 복잡성 추구 경향과 space leak 같은 런타임 문제로 인해 유지보수가 어려움
  • Go는 단순성과 빠른 컴파일, 좋은 도구 체계, 간결한 코드 이해를 가능하게 함
    • 그러나 보수적인 설계, 장황한 오류 처리, 명시적 null 검사 부재로 인해 버그 발생 가능성이 높고 불편함
    • REPL 부재와 함수형 아이디어의 부정적 태도도 한계로 언급

OCaml의 주요 강점

  • OCaml은 위의 기준을 대부분 충족하는 언어로 평가됨
    • 강한 정적 보장: 합타입, 다형 변이, 패턴 매칭 지원
    • 단순한 런타임: 가비지 컬렉션을 사용하면서도 시스템 수준 언어로 동작
    • 빠른 컴파일 속도: Dune 빌드 시스템을 통해 Haskell이나 Rust보다 빠름
    • 정적 링크된 단일 바이너리 생성으로 배포 용이
    • 우수한 문서화 도구: odig(오프라인 문서 탐색), utop(REPL), 인터페이스·구현 파일 분리 구조
  • 자동 타입 추론 기능으로 코드 작성 효율 향상
    • 인터페이스 파일에 타입을 정의하는 구조가 명확한 코드 탐색에 도움

언어 설계와 인상

  • OCaml은 오래된 언어이지만 세련된 설계 감각을 유지
    • 일부 객체지향 기능이나 복잡한 라이브러리는 불필요하다고 평가
  • 전체적으로 단순성과 표현력의 균형, 좋은 문서화와 도구 생태계가 OCaml의 핵심 매력
  • 작성자는 “단순하지만 표현력 있는 언어”로서 OCaml을 높이 평가하며, 다른 언어에서 찾기 어려운 만족감을 언급
▲
GN⁺ 21시간전  [-]
Hacker News 의견

  • OCaml을 조금 써봤는데 여러 문제가 있었음
    Windows 지원이 형편없음, OCaml 5로 와서야 “꽤 나빠진 정도”로 개선됨
    문법은 사람이 읽기 어렵고, 구문 오류가 나면 한 글자만 잘못 넣어도 1000줄짜리 에러가 뜸
    Ocamlfmt는 복잡한 match문도 한 줄로 만들어버려 가독성이 떨어짐
    문서도 지나치게 간결하고 예제가 거의 없음
    OPAM은 이론상 좋아 보이지만 실제로는 버그가 많고, 32개 이상의 Unix 그룹에 속하면 curl을 못 찾는 버그도 있었음
    함수 시그니처의 타입 주석이 선택 사항이라 정적 타이핑의 장점이 줄어듦
    생태계도 작고, 파일 복사조차 내장 함수가 없음
    단일 연결 리스트에 집착하는 것도 비효율적임
    그래도 C나 Python보다는 낫지만, Rust보다는 선택하지 않을 것 같음

    • Windows에서 OCaml을 쓰려면 차라리 F# 을 추천함
      CLR을 타깃으로 하기에 배포가 훨씬 쉽고, .NET 생태계를 그대로 활용할 수 있음
      C#이나 VB.NET용 NuGet 라이브러리를 거의 그대로 쓸 수 있어 생태계가 방대함
      F# 문서는 훨씬 풍부하고 예제도 많음
      참고 링크: F# 언어 레퍼런스, F# Core Docs, F# Cheatsheet
    • OPAM의 curl 버그가 실제로 있나 싶어 찾아봤는데, 이슈 #5373에서 확인함
      실제로는 musl 관련 문제이고, OPAM이 그 바이너리로 빌드되어 생긴 현상임
    • 대부분은 학습 곡선 문제지만, 익숙해져도 생태계 단절은 여전함
      ocamlformat은 janestreet 프로필로 설정하면 기본값이 훨씬 나음
      함수 시그니처 타입 주석 문제는 .mli 파일을 제공하면 해결되지만, 대부분 그렇게 하지 않음
      대신 VS Code용 OCaml 플러그인이 초보자에게는 최고의 경험을 줌
    • 단일 연결 리스트 집착 얘기에 공감함
      요즘 하드웨어에서는 기본 컬렉션이 vector여야 하지 않나 생각함
    • Windows 지원이 나쁘다는 점에 전적으로 동의함
      예전에는 ocaml.org에서 바로 설치조차 불가능했고, mingw나 wsl을 거쳐야 했음
      그래서 사실상 Windows용 OCaml이 없었던 셈임

  • Go 언어 설계자들이 함수형 프로그래밍의 아이디어를 거의 받아들이지 않은 이유는 명확함
    Rob Pike의 말처럼, Google의 개발자들은 대부분 젊고 C 계열 언어에 익숙한 사람들이라 쉽게 배울 수 있는 언어가 필요했음
    함수형 언어의 사고방식 전환에는 시간이 많이 들기 때문에 Go는 그 비용을 피하려 했음

    • 실제로 Go 팀의 결정에 불만을 가진 Googler도 많음

  • “ML”이라는 단어를 볼 때마다 아직도 가슴이 두근했다가, Meta Language가 아니라 Machine Learning임을 깨닫고 실망함

    • ML은 Meta Language, LLM은 Languages and Logic Montreal 연구 그룹을 의미함
    • 차라리 그런 혼동이 낫다고 생각함
      요즘 “AI”라는 단어가 남용되는 게 더 싫음
      진짜 AGI가 나오기 전까지는 AI라는 말을 쓰지 말았으면 함
    • 1980년대 후반 80286 머신에서 ML을 처음 써봤을 때 정말 충격적이었음
    • 예전에 비슷한 글을 올렸다가 다운보트를 잔뜩 받았는데, 이번엔 반응이 좋아서 반가움

  • Richard Feldman의 강연을 보면 함수형 언어가 대중화되지 못한 이유가 잘 설명됨
    플랫폼 독점 언어이거나, 킬러 앱이 있거나, 막대한 마케팅 자금이 있어야 함
    Python이 급성장한 이유도 AI 생태계의 중심 언어가 되었기 때문임
    나도 OCaml로 함수형을 배우고, Haskell과 Zig로 프로젝트를 해봤지만, 결국 “쓸 수 있는 도구를 쓴다”는 현실로 돌아오게 됨
    OCaml, Rust, Haskell은 “배우고 싶어 하는 언어”로는 인기가 있지만, “실제로 널리 쓰이는 언어”는 아님

    • Python의 인기가 AI 때문이라는 주장에는 동의하지 않음
      Torch는 원래 Lua 기반이었고, 이미 인기가 높던 Python으로 옮겨간 것임
    • 함수형 프로그래밍이 주류가 되지 못한 이유는 엘리트주의적 태도 때문이라고 생각함
      FP 진영은 현실의 기술 변화에 무관심했고, 그 사이 C, Pascal, Perl, Tcl 같은 언어들이 시장을 차지했음
      결국 FP는 “성당 안의 사제들”로 남았고, 명령형 언어가 대중을 얻었음

  • F#을 써봤는데, Actor 기반 동시성이 이해하기 쉬웠음
    다만 mutable Array가 등장하면 복잡해졌음
    OCaml을 F#보다 실무에서 선호할 이유가 궁금함

    • F#은 CLR 변화로 인해 호환성이 점점 떨어지고, 컴파일러도 느리고 툴링이 불안정함
      반면 OCaml은 글로벌 락 제거, 빠른 컴파일, 모듈·GADT·이펙트 같은 강력한 기능을 갖춤
      F#은 여전히 Windows 지원과 SIMD, 언박싱 타입에서 우위지만, OCaml도 점점 따라잡는 중임
    • F#의 .NET 통합은 양날의 검임
      라이브러리는 많지만 대부분 F#스럽지 않음
      OCaml은 네이티브 생태계가 더 큼
    • 회사에서 F#로 연산 집약적인 부분을 개발했는데,
      C#과의 상호 운용성은 좋지만, C#에서 F# 라이브러리를 쓰는 건 악몽이었음
      결국 C# 셸을 유지하게 되고, 코드베이스가 혼종이 됨
      .NET 생태계는 풍부하지만 OOP 중심 사고가 강해 FP 스타일과 충돌함
      Visual Studio는 편하지만 CLI 기반 워크플로에는 불편함
      컴파일 속도는 점점 느려지고, 테스트도 어색함
      OCaml을 써보니 언어 인체공학적 설계가 훨씬 자연스러움
    • OCaml은 functor, 모듈 1급 값, GADT, 객체 시스템 등 F#보다 훨씬 강력함
      F#은 “OCaml for .NET”이라 불리지만, 실제로는 ML 계열 언어일 뿐 거의 다른 언어임

  • OCaml이 오래된 언어라 OOP 기능은 빼도 될 것 같지만, Standard ML이 더 완벽하다고 생각함

    • 나도 SML을 좋아하지만, OCaml의 객체 시스템은 과소평가받고 있음
      구조적 타입 레코드나 open recursion, Js_of_ocaml 같은 JS 바인딩에 유용함
    • SML로 컴파일러를 작성 중인데, int/real 오버로딩이나 value restriction 같은 이상한 제약이 있음
      레코드 업데이트도 지원하지 않아 불편함
    • 예전엔 SML을 더 좋아했지만, 당시엔 “O가 붙은 언어”가 유행이라 OCaml이 주목받았음

  • OCaml은 2000년대 초부터 늘 “거의 완벽한 언어”였음
    하지만 마찰 요소가 해결될 즈음엔 이미 다른 언어들이 그 아이디어를 흡수함

    • OCaml은 Velvet Underground 같은 언어임
      배우는 사람은 적지만, 배운 사람마다 새로운 언어를 만듦
      출처
    • 그럼에도 불구하고 OCaml은 수십억 달러 규모의 거래 시스템을 실제로 운영 중임
    • “마찰”이 뭔지 모르겠음
      이미 많은 프로젝트가 OCaml로 잘 돌아가고 있고,
      이펙트 시스템까지 추가되어 오히려 더 앞서가고 있음

  • 인기와 실력은 다름
    인기 ≠ 우수함, 음악에서도 마찬가지임
    트렌드와 관성에 의해 결정될 뿐임

    • 인기와 호감도는 오히려 역상관 관계임
      많이 쓰이는 언어일수록 싫어하는 사람도 많고,
      생소한 언어일수록 과대평가되기 쉬움
    • 음악의 “좋음”은 주관적이지만, 언어의 “좋음”은 문제 해결 효율성으로 객관화 가능함
      OCaml이 덜 인기인 이유는 그 효율을 체감하는 사용자층이 작기 때문임
      그리고 FP 진영의 교조적 태도도 한몫함

  • Elixir는 OCaml과 비슷하면서도 대중화 가능성이 있는 언어라고 생각함
    불변성, 패턴 매칭, Actor 모델 등 FP의 장점을 갖추고,
    BEAM 런타임 위에서 안정적으로 동작함
    정적 타이핑은 없지만 점진적 타입 검사를 도입 중임

    • 사실 더 궁금한 건 왜 F#이 더 인기가 없는가임
      .NET 생태계를 그대로 쓸 수 있는데도 OCaml보다 덜 알려져 있음
    • Elixir는 생태계와 툴링이 훌륭하고, 문법도 Erlang보다 친숙함
      실제로 SaaS 백엔드에 쓰는 회사도 많음
    • 하지만 대부분의 조직은 함수형 패러다임(재귀 중심) 을 부담스러워함
      그래서 FP 언어는 여전히 비주류임
    • 개인적으로는 OCaml보다 Elixir가 두뇌 부담이 적고 유연함
    • Gleam도 흥미롭지만, 컴파일되지 않는 언어는 내 작업에는 맞지 않음

  • OCaml은 GC 기반 시스템 언어라는 점에서 Go와 비슷함
    수동 메모리 관리나 borrow checking보다 GC를 선호함
    D 언어의 GC도 훌륭했지만, “GC”라는 단어 자체가 사람들을 겁먹게 했던 게 문제였음

답변달기