Flix – 강력한 효과 지향 프로그래밍 언어

 (flix.dev)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Flix는 Aarhus University와 오픈소스 커뮤니티가 개발하는 효과 지향 언어로, 함수형·명령형·논리 프로그래밍을 한 언어 안에서 결합함
  • 핵심은 부작용을 타입 수준에서 다루는 효과 시스템이며, 순수성 추적·사용자 정의 효과·핸들러·다중 재개로 모듈성과 추론 가능성을 높임
  • 언어 표면은 대수적 데이터 타입, 패턴 매칭, 확장 가능한 레코드, 트레이트, 고차 kind 타입, 연관 타입·효과, 구조적 동시성, Java 상호운용성, 내장 Datalog까지 폭넓음
  • 표준 라이브러리는 3,100개 이상 함수를 제공하고, Maven을 통해 Java 생태계에도 접근할 수 있어 연구용 언어에 그치지 않는 사용 범위를 지향함
  • 컴파일러는 JVM 바이트코드를 타깃으로 하며 병렬·증분 구조를 갖고, 24코어 머신에서 5x–7x 속도 향상과 Apple M2 Pro/OpenJDK 21 기준 60,159 lines/sec 처리량을 내세움

Flix의 언어 방향

  • Flix는 원칙 기반의 효과 지향 언어로, 함수형·명령형·논리 프로그래밍을 결합함
  • 개발 주체는 Aarhus University와 오픈소스 기여자 커뮤니티임
  • 효과 시스템은 부작용을 명시적으로 모델링해 모듈성과 프로그램 추론을 돕는 정적 타입 언어의 핵심 축임
  • 사용자 정의 효과와 핸들러를 통해 프로그래머가 직접 제어 구조를 구현할 수 있음
  • Flix는 효과 지향 언어 중 완성도 높은 구현, 넓은 표준 라이브러리, 자세한 문서, 도구 지원을 강점으로 내세움

타입, 순수성, 효과 시스템

  • Flix는 함수형 프로그래밍의 기본 요소인 대수적 데이터 타입과 패턴 매칭을 지원함
  • 튜플과 레코드를 내장 지원하며, 레코드는 구조적 타이핑을 사용하고 확장 가능함
  • 컴파일러는 프로그램 안 모든 표현식의 순수성을 정밀하게 추적함
    • 표현식이 순수하면 부작용이 없고 참조 투명하다는 보장을 제공함
  • 고차 함수에서도 효과 다형성으로 순수성을 추적함
    • 예를 들어 List.map의 순수성은 인자로 받는 함수 f의 순수성에 따라 달라짐
  • 대수적 효과는 사용자 정의 효과와 핸들러를 가능하게 함
    • Flix는 특히 multi-shot resumptions를 지원함
    • 효과 핸들러는 프로그램 추론, 모듈성, 테스트 가능성을 높이는 데 쓰임

지역 기반 변경과 순수성 반영

  • Flix는 지역 기반 로컬 변경을 지원해, 변경 가능한 상태와 파괴적 연산을 내부적으로 쓰면서도 외부에는 순수 함수로 보이게 할 수 있음
  • 변경 가능한 데이터로 작성하는 편이 자연스러운 함수나, 정렬 알고리듬처럼 변경 가능한 자료구조가 더 효율적인 경우에 적합함
  • 순수성 반영은 고차 함수가 함수 인자의 순수성을 검사하고 그 정보에 따라 동작을 바꾸는 메타프로그래밍 구조임
    • DelayList.map은 인자 함수의 순수성에 따라 즉시 평가와 지연 평가 사이에서 동작을 바꿈
    • 라이브러리 내부에서 지연 평가나 병렬 평가를 선택적으로 사용해도 클라이언트 관점의 의미는 바뀌지 않을 수 있음

병렬성, 동시성, 추상화

  • Flix는 순수 코드를 병렬로 평가하기 쉽게 만들며, par 구조로 List.map의 병렬 구현을 작성할 수 있음
  • par 구조는 내부적으로 경량 VirtualThread를 사용함
  • 구조적 동시성을 지원해, 특정 지역 안에서 생성된 스레드는 해당 지역의 생명주기를 벗어나 살아남을 수 없음
    • 예시에서는 rc라는 새 지역 안에서 두 스레드를 생성함
    • 제어 흐름은 두 스레드가 모두 종료되기 전까지 지역을 벗어나지 않음
  • 공통 연산을 지원하는 타입 추상화에는 트레이트를 사용함
    • Eq 트레이트는 동등성 개념을 표현하며 표준 라이브러리 전반에서 사용됨
  • 고차 kind 타입으로 타입 생성자를 추상화할 수 있음
    • Option과 List는 모두 Foldable을 구현함
    • 표준 라이브러리는 Monoid, Functor, Foldable 같은 공통 트레이트를 포함함

연관 타입·효과와 for-yield

  • Flix는 인스턴스 시그니처의 타입이 인스턴스 타입에 의존할 수 있게 하는 연관 타입을 지원함
    • Coll 트레이트 예시는 연관 타입 Elm을 통해 각 컬렉션 인스턴스가 원소 타입을 정의할 수 있게 함
  • 연관 효과는 트레이트 멤버의 효과가 인스턴스 타입에 의존하도록 만듦
    • 순수 연산과 효과가 있는 연산, 변경 가능한 자료구조와 불변 자료구조를 함께 추상화하기 쉬움
    • Coll 트레이트에 연관 효과 Aef를 추가하면 변경 가능한 컬렉션 인스턴스를 추가할 수 있음
  • forM-yield는 Scala의 for-comprehension, Haskell의 do 표기와 유사한 단항 구조임
    • Monad 트레이트가 제공하는 point와 flatMap을 쓰기 위한 문법 설탕임
  • forA는 Applicative 트레이트 기반의 적용형 표현식임
    • Validation[e, t] 데이터 타입을 사용하는 오류 처리 코드를 쉽게 작성하도록 돕는 구조임

Java 상호운용성과 Datalog

  • Flix는 Java Standard Library와 Java 생태계 코드를 재사용할 수 있는 Java 상호운용성을 지원함
    • Maven을 통한 생태계 접근을 포함함
    • 객체 생성, 메서드 호출, 예외, 클래스·인터페이스 확장을 지원함
  • 내장 Datalog 지원은 Flix의 고유 기능 중 하나임
    • Datalog는 그래프 도달 가능성 문제를 포함한 여러 고정점 문제를 간결하게 표현할 수 있음
  • Datalog 제약은 일급 값임
    • 함수에 전달하거나 함수에서 반환할 수 있음
    • 자료구조에 저장할 수 있음
    • 다른 Datalog 제약과 합성하고 해결할 수 있음
    • 이를 통해 Datalog 프로그램 계열을 표현할 수 있음
  • Flix는 격자 의미론이 풍부해진 Datalog 제약도 지원함
    • 부품과 하위 구성품의 배송일을 계산하는 예시가 있음
    • 자동차는 섀시와 엔진에 의존하며, 각 구성품 조립을 기다린 뒤 자동차를 조립할 수 있음
    • 하위 구성품도 다른 하위 구성품에 의존할 수 있어 문제가 재귀적임
  • 격자 의미론을 포함한 Datalog 제약은 Flix의 고급 기능 중 하나이며, 격자 이론과 고정점 배경지식이 필요함

표준 라이브러리와 기능 목록

  • Flix는 3,100개 이상 함수를 제공하는 표준 라이브러리를 포함함
    • List 모듈은 100개 이상 함수를 제공함
    • Foldable 트레이트는 47개 이상 함수를 제공함
    • 전체 라이브러리는 api.flix.dev에서 탐색할 수 있음
  • 기능 목록에는 다음이 포함됨
    • 대수적 데이터 타입, 패턴 매칭, 일급 함수
    • 확장 가능한 레코드, 매개변수 다형성
    • 트레이트, 고차 kind 타입, 연관 타입과 효과
    • 효과 다형성과 하위 효과, 순수성 반영
    • CSP 스타일 동시성, 버퍼 있는 채널과 버퍼 없는 채널
    • 일급 Datalog 제약, Java 상호운용성
    • 언박스드 원시 타입, 키워드 기반 문법
    • forM, forA, 표현식 hole
    • JVM 바이트코드 컴파일, 완전한 꼬리 호출 제거
    • 탄력적·병렬 컴파일러 구조, 사람이 읽기 쉬운 오류

컴파일러 구조와 성능

  • Flix 컴파일러는 탄력적·증분·병렬 구조를 갖춤
  • 모든 컴파일러 단계가 병렬이며, 24코어 머신에서 각 단계의 속도 향상을 활용할 수 있음
  • 멀티코어 머신에서는 5x–7x 속도 향상이 가능함
  • 같은 컴파일러 인스턴스에서 이미 컴파일된 코드를 다시 컴파일할 때 증분 컴파일로 상당한 속도 향상을 얻을 수 있음
  • Apple M2 Pro 10코어 CPU와 OpenJDK 21 기준 성능 수치는 다음과 같음
    • 전체 컴파일러 처리량: 60,159 lines/sec
    • 프런트엔드 전용 처리량: 140,382 lines/sec
    • 재현 명령은 java -jar flix.jar Xperf --n 21 및 java -jar flix.jar Xperf --frontend --n 21
  • 이 성능은 타입·효과 추론, 단형화, 전체 프로그램 최적화 같은 비용이 큰 언어 기능을 지원하면서 달성한 수치임
  • 컴파일러 성능은 주로 CPU 성능과 메모리 대역폭에 의해 결정됨

Visual Studio Code 지원과 도구 통합

  • Flix 컴파일러는 Visual Studio Code와 통합되어 개발 환경을 제공함
  • VSCode 확장은 실제 Flix 컴파일러를 사용하므로 확장과 컴파일러 사이에 1:1 대응이 있음
    • VSCode가 오류를 보고하지 않으면 오류가 없음
    • 오류가 없을 때 VSCode가 가짜 오류를 보고하지 않음
  • VSCode 확장은 다음 기능을 지원함
    • 의미 기반 구문 강조
    • 인라인 컴파일러 오류 진단
    • 입력 중 자동완성, 문맥 인식 자동완성, 트레이트 인스턴스 자동완성, 타입 기반 hole 완성
    • 스니펫과 인레이 힌트
    • 표현식의 타입과 효과를 보여주는 hover
    • 함수, 지역 변수, enum 정의로 이동
    • 함수·지역 변수·enum 참조 찾기와 트레이트 구현 찾기
    • 문서·워크스페이스 심볼 목록
    • 지역 변수와 함수 이름 변경
    • 에디터에서 main 실행과 테스트 실행
  • Flix는 많은 도구를 컴파일러에 직접 내장함
    • OCaml은 LSP로 ocaml-lsp, REPL로 utop, 빌드 도구로 dune, 패키지 관리자로 opam을 사용함
    • Haskell은 LSP로 HLS, REPL로 ghci, 빌드 도구와 패키지 관리자로 cabal, stack, 패키지 저장소로 Hackage를 사용함
    • Flix는 컴파일러, LSP, REPL, 빌드 도구, 패키지 관리자를 모두 flix로 제공하며 패키지 저장소는 GitHub임

개발 상태, JVM 타깃, 프로젝트 규모

  • Flix는 덴마크 Aarhus University의 프로그래밍 언어 연구자들이 개발·유지함
  • 협력 기관은 캐나다 University of Waterloo, 독일 University of Tubingen, 덴마크 Copenhagen University임
  • 전 세계 오픈소스 기여자 커뮤니티의 개발 참여가 늘고 있으며, 기여를 초대함
  • 프로젝트 통계는 다음과 같음
    • 병합된 Pull Request: 4,900개 이상
    • 해결된 이슈: 3,100개 이상
    • 기여자: 70명 이상
    • 컴파일러 코드베이스: 272,000줄 이상
  • Flix는 JVM을 타깃으로 함
    • JVM에는 OpenJDK, J9, Azul, Graal 등 검증된 오픈소스·상용 구현이 있음
    • Mac, Linux, Windows에서 사용할 수 있음
    • 현대 JVM은 여러 최신 가비지 컬렉터를 제공함
    • Java 21의 경량 스레드를 포함해 동시성과 병렬성 지원이 좋음
    • 디버거와 프로파일러를 포함한 도구 지원이 있음
    • Maven 통합을 통해 Java 플랫폼의 풍부한 패키지 생태계에 접근할 수 있음
  • 총 펀딩은 110만 유로이며, 프로젝트의 연속성과 독립성을 보장하는 데 도움을 줌

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 언어의 깊이와 폭이 인상적임. 대수적 데이터 타입, 논리 프로그래밍, 가변성이 처음부터 모두 들어 있음
    비교표에서 마음에 든 또 다른 점은 단일 실행 파일이 패키지 관리자, LSP, 컴파일러 역할을 모두 한다는 점임. Haskell의 언어 서버는 특정 ghc 버전과 cabal 파일 사이에서 많은 우회와 재구현을 해야 했고, 요즘은 어떤 패키지 관리자가 공식에 가까운지도 헷갈림. Haskell을 깎아내리려는 건 아니고, 실제로 아주 좋은 언어임
    다만 최고의 기능이 좀 묻혀 있는 듯해서 궁금함. Java 같은 JVM 생태계와의 통합은 얼마나 쓰기 편한가? 알기로 JVM 컴파일러는 타입을 소거하는데, regions 개념 덕분에 명령형 상호작용은 일급으로 지원하는 듯함
    JVM을 쓰면 고품질 전문 표준 라이브러리와 방대한 코드 자산을 얻으니 큰 장점이고, 그래서 JVM과 .NET Core가 프로젝트의 90% 이상에서 가장 합리적인 선택이라고 봄. 비교할 만한 언어는 F# 정도일 듯함. Flix의 JVM 상호운용 한계에 대한 문서가 있으면 좋겠음
    편집: 여기 정보가 조금 있음. 기본적으로 Flix/Java 값은 모두 박싱/언박싱이 필요함: https://doc.flix.dev/interoperability.html
    레코드는 일급 시민임

    • “단일 실행 파일이 패키지 관리자, LSP, 컴파일러를 겸한다”면 Unison도 아주 마음에 들 듯함
    • JVM 컴파일러가 항상 타입을 소거하는 건 아님. 익명 클래스에는 타입 매개변수를 남기기도 하고, 여러 우회 방법도 있음
      본질적으로 컴파일러 입장에서는 큰 문제가 아님. 적용된 타입 생성자를 이름 변형된 일반 클래스로 렌더링하면 됨
    • 논리 프로그래밍 / Datalog는 다른 기능들 위에 붙은 장난감처럼 느껴짐. 다른 기능들은 코드베이스의 타입 건전성을 어떻게 높일지 명확히 보이는데, 논리 프로그래밍은 꽤 틈새라 언어와 독립되어 있는 편이 차라리 낫겠다고 봄
    • F#에는 아직 타입 클래스가 없어서 모나드로 프로그래밍하는 데 한계가 꽤 있음
      F#이 Haskell식 모나드를 건너뛰고 바로 대수적 효과로 가면 흥미로울 듯함. 어차피 F# 철학에는 그쪽이 더 잘 맞아 보임

  • 언어 의미론 관점에서, 다형적 레코드의 확장/제한 의미론은 범위가 있는 레이블을 쓰는 Leijen 방식 [0]을 따르는 듯함
    예를 들어 r1 = { color = "yellow" }가 있을 때 r2 = { +color = "red" | r1 }로 확장하면 r2#color는 "red"가 됨. 이후 "color" 필드를 제거해서 r3 = { -color | r2 }를 만들면 원래 레코드로 돌아가고, r3#color는 "yellow"가 됨
    개인적으로 이게 가장 온전한 방식이라고 봄. 같은 레이블을 가진 두 필드가 레코드에 다시 추가되지 못하게 하려고, 그것도 정적으로 막으려고, 놀랄 만큼 고차원적인 타입 시스템을 만들어 레코드 레이블을 추적하던 이전 시도들보다 낫다
    [0] https://www.cs.ioc.ee/tfp-icfp-gpce05/tfp-proc/21num.pdf

  • 조금 벗어난 질문이지만, Aarhus가 왜 프로그래밍 언어 분야의 강자인지 궁금함
    C++, C#/TypeScript, Dart 등도 덴마크의 그 작은 지역에 강한 뿌리가 있음. Delft, INRIA 같은 곳도 마찬가지로 왜 특별해지는지 궁금함
    전형적인 Ivy League/Oxbridge 대학+기술 허브도 아닌데, 물 때문인가? 아니면 다른 뭔가가 있나? :)

    • 작은 정정: C#은 Anders Hejlsberg가 만들었고 그는 DTU, 즉 Copenhagen에서 공부했음. Turbo Pascal도 그가 구현했고, Borland도 덴마크인들이 세운 회사임
      전반적으로 덴마크는 프로그래밍 언어 이론이 꽤 강하고 기여도 많음. 예를 들어 정적 프로그램 분석의 표준 대학원 교재인 Nielson & Nielson도 덴마크 출신이고, Mads Tofte도 Standard ML에 많은 기여를 했음
      Aarhus는 뛰어난 대학임. 유럽에는 Oxbridge만큼의 명성은 없어도 고품질 교육과 훌륭한 연구를 하는 대학이 수십 곳 있음
    • 계보 때문일 듯함. Aarhus는 논리, 타입 이론, 함수형 프로그래밍, 객체지향 언어 같은 분야에서 강한 학문적 전통이 있고, 이 분야의 영향력 있는 연구자들이 많이 거쳐 갔음
      전 세계적으로 프로그래밍 언어 연구를 바라볼 때 미국 쪽으로 편향이 꽤 있다고도 봄. Aarhus 같은 기관은 마케팅이나 자기 홍보에 크게 투자하지 않고 탄탄한 작업에 집중하는 경우가 많음. 더 낫거나 나쁘다는 뜻은 아니지만, 그들의 기여가 전 세계적인 관심의 층을 뚫고 나오기 어렵게 만들긴 함

  • 예전에 Flix를 살펴봤고 정말 흥미로워서 “Flix for Java Programmers”라는 글도 썼음. 지금은 좀 낡았을 수 있어서 최근 Flix 개발 상황을 다시 봐야 할 듯함
    관심 있으면 여기 있음: https://www.reactivesystems.eu/2022/06/24/flix-for-java-prog...

    • 멋진 블로그 글임. 허락해 준다면 여기에 추가하고 싶음: https://doc.flix.dev/blog-posts.html
      글이 나온 뒤 몇 년 동안 언어가 많이 개선됐음. 특히 효과 시스템이 크게 확장됐고, Java 상호운용도 훨씬 좋아졌으며, 일부 문법도 업데이트됨
    • 블로그가 정말 금광 같음. 몇 년 동안 나를 괴롭히던 생각들을 더 정교하고 잘 정리해 둔 버전처럼 느껴짐. 전부 읽어볼 생각에 기대됨

  • 언어가 아무리 강력해도 상관없으니, 제발 \ 문자를 이스케이프 외의 용도로 쓰지 말아 줬으면 함

  • 훌륭함, 고차 kind 타입도 지원함
    타입 클래스 언급은 못 찾겠는데 지원하나? Scala 매크로에 견줄 만한 매크로와 타입 클래스를 주면 내 라이브러리들(distage, izumi-reflect, BIO)을 Flix로 포팅하고 Scala에서 옮기는 것도 고려할 듯함
    업데이트: 아, 타입 클래스를 traits라고 부르는군. 매크로는 어떨까?
    업데이트2: 으, Scala traits의 가장 무해한 형태 같은 이름 기반 상속도 지원하지 않음. 타입 클래스는 인터페이스의 대체물이 아니고, 매우 중요한 추상화가 언어에 빠져 있음. 아마 Hindley-Milner 타입 추론 때문일 수도 있는데, 그래서 유용한 많은 것들이 불가능하거나 보기 흉해질 듯함

    • Flix는 traits라고 부르는 타입 클래스를 지원하고, 고차 kind 타입, 연관 타입, 연관 효과도 함께 지원함
      Flix trait는 함수의 기본 구현을 제공할 수 있고, 구체적인 trait 인스턴스가 그 구현을 재정의할 수도 있음. 다만 Flix에는 상속이 없음
      장점은 traits가 컴파일 타임 구조이며 단형화로 완전히 제거된다는 점임. 따라서 런타임 오버헤드가 없음. 더 좋은 점은 Flix 인라이너가 traits를 “뚫어볼” 수 있어서 공격적인 클로저 제거가 자주 가능하다는 것임. 예를 들어 고차 함수나 파이프라이닝의 일반적인 사용은 바이트코드 수준에서 클로저 할당이나 간접 참조 없이 평범한 루프로 줄어듦
      Flix에는 아직 매크로가 없음. 다른 프로그래밍 언어에서 실제로 또는 인식상 남용되는 사례 때문에 추가를 조심하고 있음
      라이브러리 작성자를 적극적으로 찾고 있으니 관심 있으면 Gitter 채널에 들러도 좋음

  • 이 언어와 잘 맞는 코드 에이전트가 있나, 아니면 다시 우리 뇌로 생각해야 하나?
    진지하게 말하면 멋진 언어로 보이지만, LLM이 새 언어의 채택을 막을 것 같아 아쉽고, 이에 대해 뭘 할 수 있을지도 궁금함

    • LLM에 대해서는 반대로 직감함. 코드 이식 비용을 크게 낮출 테니 새 프로그래밍 언어 채택 장벽을 허물 가능성이 있다고 봄
      언어 표준 라이브러리의 코드만으로도 LLM이 새 문법을 학습하기에 충분할 수 있고, 부족하더라도 요즘 에이전트는 컴파일러 출력을 관찰하므로 원칙적으로 거기서 배울 수 있음
      한 언어에서 다른 언어로 코드를 이식하는 일은 깊은 창의성이 필요한 작업이 아니고, API 미감만 빼면 꽤 잘 정의된 작업임. LLM이 완전히 자동화할 첫 프로그래밍 작업 중 하나가 될 것임
      이제 우리는 왜 이런 일을 하는지, 그 일이 세상에 어떤 영향을 줄지 다시 머리로 생각해야 할 것임
    • 기본 프롬프트에 Idris와 색인 타입/의존 타입을 쓰라고 지시하면 좋은 결과가 나왔음. 그렇게 하지 않으면 가장 대담해 봐야 GADT 정도까지임

  • Flix FAQ(https://flix.dev/faq/)는 처음엔 평범한데 뒤로 갈수록 점점 웃겨짐 :D
    몇 가지 보석 같은 항목:
    Q: 잠깐, 0으로 나누면 정말 0인가요?
    A: 네. 하지만 여기에 집중하는 건 우주선 좌석 색깔에 집중하는 것과 조금 비슷합니다
    Q: “이 사이트는 JavaScript가 필요합니다”
    A: 웹사이트가 JavaScript를 쓴다고 비판한 사람: [1], [2], [3], [4], [5]. 사이트를 정적 HTML로 리팩터링하겠다고 도와준 사람: 0
    Q: Flix가 제가 좋아하는 기능 Y 대신 기능 X를 가진 걸 알고 실망했습니다
    A: 실망시켜 드려 진심으로 죄송합니다
    Q: 이건 단연 제가 본 함수형 언어 중 최악의 문법입니다. 세미콜론, 중괄호, 기호 수프 등등. Scala, Java, Haskell이 Chernobyl 한가운데서 하룻밤을 보낸 것 같습니다
    A: 꽤 대단한 성취 아닌가요?

  • 문법은 마음에 들고 만져보는 것도 기대되지만, JVM 위에 있다는 점은 아쉬움. 추측하자면 이런 언어들이 JVM 위에 올라가는 이유는 비슷한 성능과 신뢰성을 가진 백엔드를 통째로 쓰는 것보다 훨씬 쉽기 때문일 테고, 그건 충분히 이해됨
    다만 Java/JVM 개발자가 아니고 가끔만 쓰는 입장에서, JVM으로 출시한 몇몇 비사소한 프로젝트에서는 빌드 시스템이 압도적으로 가장 어렵고 답답했음. 너무 복잡하고 표면적이 큼
    비난하려는 건 전혀 아니고 절충도 완전히 합리적이지만, 커리어 동안 JVM 빌드가 크게 단순해지거나 네이티브 컴파일러를 더 쉽게 만들 수 있는 혁신이 많이 나오길 바람
    덧붙이면 JVM이 유일한 선택지일 때 이런 언어가 있는 건 좋음

    • 내가 이해하기로는 일반적인 “JVM 빌드”라는 건 없음. JVM은 대상일 뿐이고, x64 빌드가 복잡하다고 말하는 것과 비슷함. 아마 ant, maven, gradle 같은 걸 생각하는 듯함. 그 외에도 많음
      기본적인 Java는 javac myfile.java로 빌드하면 끝임
      각 JVM 언어는 자기 빌드 도구가 있고, 일부 빌드 도구는 여러 JVM 언어와 그 외 언어를 함께 다룸

  • JS 생태계에 있다면 Effect TS(https://effect.website)를 확인해볼 만함
    요즘 정말 재미있는 시기임

    • 이름은 effect지만, 이 언어와 OCaml 5 같은 곳에 있는 대수적 효과와는 거의 관련이 없음. Effect TS는 fp-ts에서 왔기 때문에 Haskell에 더 가까움
    • Effect TS는 모나드 방식임. Scala의 ZIO를 꽤 직접적으로 다시 구현한 것에 가까움
답변달기