The State of Full-Stack OCaml (with Antonio Monteiro) .mdx

https://www.youtube.com/watch?v=vSSpbAI_-t0&pp=ygU1VGhlIFN0YXRlIG9mIEZ1bGwtU3RhY2sgT0NhbWwgKHdpdGggQW50b25pbyBNb250ZWlybyk%3D

이번 주에는 OCaml 컴파일러와 그 컴파일러의 영역을 확장하는 방법에 대해 알아보겠습니다. OCaml은 항상 백엔드 언어였지만, 이제는 브라우저까지 목표로 삼고 있습니다. 오늘 저와 함께 OCaml이 JavaScript 세계로 진출하도록 돕는 흥미롭고 정교한 컴파일러 작업을 많이 해온 Antonio Monteiro가 함께합니다. 또한 기존 JavaScript 개발자들이 OCaml의 함수형 세계로 넘어올 수 있도록 돕기도 합니다. 그는 OCaml 컴파일러를 두 가지 측면에서 확장하여 이를 수행하고 있습니다. 첫째, OCaml을 작성하고 JavaScript를 생성할 수 있게 해주는 Melange의 제작자입니다. 둘째, JavaScript와 매우 유사하게 보이지만 타입 안전 백엔드 네이티브 OCaml을 생성하는 ReasonML의 주요 기여자입니다. 물론 첫 번째 질문은 "왜?"입니다. 왜 그렇게 하고 싶어할까요? OCaml이 브라우저에 넣을 만큼 훌륭한 점은 무엇일까요? 그리고 Antonio는 OCaml의 어떤 점이 그렇게 훌륭하다고 생각할까요? 이 모든 작업을 하는 그의 개인적인 이유는 무엇일까요? 하지만 훨씬 더 흥미로운 질문은 "어떻게?"입니다. 두 가지 다른 언어 사이에서 어떻게 컴파일하고 트랜스파일할까요? 물론 한 언어의 for 루프 구문을 파싱하고 다른 for 루프 구문을 생성하는 것은 사소한 일이지만, 동시성 모델이 다르거나 OCaml의 일급 모듈 시스템을 JavaScript 세계로 이식하는 것과 같은 주요 차이점은 어떻게 처리할까요? 이러한 질문에 답하려면 전문가의 머리를 좀 빌려야 합니다. 저는 여러분의 호스트 Chris Jenkins이고, 이것은 Developer Voices이며, 오늘의 목소리는 Antonio Monteiro입니다!

Chris Jenkins: 오늘 저와 함께해 주신 Antonio Monteiro입니다. Antonio, 안녕하세요?

Antonio Monteiro: 안녕하세요. 잘 지내고 있습니다.

Chris Jenkins: 저는 자주 가지 않는, 사실 한 번도 가본 적이 없는 세상으로 저를 안내해 주시려고 합니다. 바로 OCaml입니다. 정말 기대됩니다. OCaml 프로젝트 목록을 쭉 살펴봐야 할 것 같지만, OCaml에 푹 빠져 있다고 해도 과언이 아니죠?

Antonio Monteiro: 그렇습니다. 처음에는 천천히 시작했지만, 그 후에는 정말 빠르게 따라잡았죠.

Chris Jenkins: 어떻게 시작하게 되었나요? OCaml에 끌리게 된 계기는 무엇이었나요?

Antonio Monteiro: 대학에서 OCaml을 처음 접했습니다. 아마 13~15년 전쯤이었을 겁니다. OCaml 수업이 있었는데, 그때까지 배웠던 언어와는 매우 달랐습니다. 흥미로웠지만, 그 당시에는 수업 프로젝트만 하고 제쳐두었습니다. 실제 세계에서 그 가치를 알 수 없었거든요. 그러다가 2016년에 Hacker News에서 ReasonML을 보고 다시 살펴보게 되었습니다. Jordan Walke가 Facebook에서 발표한 ReasonML 프로젝트를 보았는데, 그 이름이 익숙했습니다. "OCaml이라는 말을 들어본 적이 있는데, 왜 새로운 모습을 하고 있는 거지? 왜 필요할까? 이걸로 무엇을 할 수 있을까?"라는 생각이 들었습니다. 그래서 한번 시험해 보기로 했고, 솔직히 말해서 설치부터 에코시스템, 빌드 도구까지 모든 것이 정말 힘들었습니다. 그 당시에는 시작하기가 정말 어려웠습니다. 아마도 그래서 많은 사람들이 사용하지 않았던 것 같습니다. 하지만 계속 사용해 보면서 언어 개념을 이해하기 시작했고, Discord와 Slack 커뮤니티에 가입해서 도움을 받았습니다. 설치 방법, 도구 등 여러 가지를 시도해 보았고 결국에는 이해하게 되었습니다. 오늘날 제가 OCaml을 계속 사용하는 이유는 인체 공학적인 타입 시스템, Hindley-Milner 기반의 훌륭한 타입 추론, 광범위한 커뮤니티, 훌륭한 모듈 시스템 때문입니다. OCaml에서 특정 사용 사례에 맞는 라이브러리를 찾을 수 없더라도, 타입과 대수적 데이터 타입으로 프로그램을 정의하고, 정의한 타입에서 프로그램을 파생시킬 수 있다는 점이 정말 매력적입니다. 모든 것이 컴파일되고 작동하는 프로그램을 갖게 되는 것은 마법 같은 느낌, 좋은 도파민 분비와 같습니다. 계속해서 더 많은 것을 쓰고 언어로 더 많은 것을 시도하게 만듭니다. OCaml은 C, C++, 심지어 Rust와의 훌륭한 FFI(외부 함수 인터페이스)를 가지고 있어서 프로그램을 마치 C 라이브러리에 링크된 것처럼 모델링할 수 있습니다. 그래서 서로 호출할 수 있습니다.

Chris Jenkins: Haskell과 많은 부분이 겹치는 것 같습니다. 어느 대학에서 어떤 이상한 함수형 언어를 가르치느냐에 달려 있는 것 같습니다.

Antonio Monteiro: 맞습니다.

Chris Jenkins: OCaml을 이해하게 된 특별한 순간이 있었나요? 아니면 점차 이해하게 되었나요?

Antonio Monteiro: Bloomberg에서 시작된 BuckleScript 프로젝트가 생각납니다. 이 프로젝트의 목표는 OCaml과 ReasonML을 JavaScript로 컴파일하는 것이었습니다. 제가 OCaml을 시작했을 때는 아마도 OCaml을 처음 사용하는 사람들에게 가장 잘 다듬어진 워크플로우였을 겁니다. 참고로 저는 JavaScript와 JVM 프로그래머였습니다. Closure를 많이 사용했고, 인터프리터 언어에 대한 경험만 있었기 때문입니다. 대학에서 C++를 조금 해보았지만, makefile을 사용했을 겁니다. 그래서 컴파일 언어와 워크플로우는 조금 달랐습니다. 이전에 Go를 사용해 보았지만, Go는 모든 것이 하나의 명령어로 잘 통합되어 있습니다. 반면 OCaml은 모든 것이 조금 분산되어 있고, 어떤 면에서는 조각난 느낌이었습니다. BuckleScript는 이러한 경험을 통합하려고 노력했습니다. Facebook 내부에서도 열심히 작업했던 것으로 알고 있습니다. 한때 messenger.com의 50%가 ReasonML로 작성되고 BuckleScript로 컴파일되었다고 합니다. 그래서 저에게는 BuckleScript가 딱 맞았습니다. npm 설치로 OCaml 모듈을 볼 수 있었습니다. 오늘날 우리가 사용하는 도구로는 정말 사소한 일처럼 들리지만, 당시에는 꼭 그렇지 않았습니다. 적어도 저에게는 그랬죠. 하지만 몇 개의 라이브러리와 모듈을 조합해서 작동하는 JavaScript 프로그램을 얻을 수 있다는 점이 정말 매력적이었습니다. 그 이후로 저의 목표는 네이티브 프로그램에서도 동일한 경험을 하는 것이었습니다.

Chris Jenkins: 언어에 대해 말하자면, 컴파일할 수만 있다면 툴체인만 제대로 갖추면 작동합니다. 똑같은 경험이죠. BuckleScript를 언급하셨는데, 저는 OCaml 에코시스템을 잘 모릅니다. 구문 프런트엔드인 ReasonML과 컴파일 백엔드인 BuckleScript가 있는데, BuckleScript는 더 이상 사용되지 않거나 이름이 바뀐 프로젝트인가요?

Antonio Monteiro: 자세히 설명해 드리겠습니다. 제가 처음 시작한 것은 Hacker News에서 ReasonML을 보고 언어를 시험해 보기로 한 것이었습니다. 먼저 OCaml은 여러 가지를 의미하는 포괄적인 단어입니다. OCaml 컴파일러는 OCaml 구문을 가져와서 네이티브 프로그램이나 바이트코드 프로그램으로 컴파일하여 실행할 수 있는 툴체인입니다. 컴파일러는 실제로 바이트코드 가상 머신과 네이티브 어셈블리로 프로그램을 컴파일하는 컴파일러라는 두 가지 백엔드를 제공합니다. OCaml의 특징은 특히 컴파일러 프런트엔드에서 매우 플러그형이라는 것입니다. 컴파일러 프런트엔드는 구문, 전처리기 확장을 의미합니다. ReasonML은 지금도 그렇지만 기본적으로 표면 구문을 다른 것으로 대체하는 것입니다. 따라서 OCaml 언어를 쓰는 대신 Alol 구문을 사용해 본 사람들에게 익숙한 ReasonML을 쓰는 것입니다. JavaScript, C, OCaml, Rust, Go와 매우 유사하게 보입니다.

Chris Jenkins: 프로그래머에게 익숙한 기본 구문, 요즘 모두가 배우거나 적어도 어느 시점에는 익숙해지는 구문이죠. 이것이 바로 ReasonML입니다. OCaml의 다른 구문일 뿐입니다.

Antonio Monteiro: BuckleScript 또는 컴파일러 백엔드에 대해 말씀드리겠습니다. OCaml 컴파일러에는 바이트코드 가상 머신과 네이티브 어셈블리로 프로그램을 컴파일하는 기능이 있다고 말씀드렸습니다. 컴파일러가 생성하는 일종의 중간 표현을 가져와서 JavaScript로 컴파일하는 도구도 있습니다. 제가 아는 한 가장 먼저 존재했던 도구는 js_of_ocaml입니다. js_of_ocaml은 바이트코드 가상 머신이 해석하는 것과 동일한 바이트코드, 즉 OCaml 바이트코드를 컴파일 타임에 해석하여 웹이나 JavaScript가 실행되는 모든 곳에서 실행할 수 있는 JavaScript를 생성합니다.

Chris Jenkins: 그 부분은 이해가 됩니다. 나중에 장단점에 대해 자세히 알아보겠지만, BuckleScript가 한 일은 람다 미적분학과 훨씬 더 유사하게 보이는 초기 컴파일러 중간 표현에 연결하는 것이었습니다. 몇 단계 아래에 있겠죠?

Antonio Monteiro: 정확히 그렇습니다. 순서는 구문(OCaml 또는 Reason), 추상 구문 트리, 타입 추론, 타입 검사 알고리즘 실행, 타입 추상 구문 트리로 추상 구문 트리를 보강하는 순서입니다. 이 시점에서 프로그램에 대한 모든 정적 정보를 얻게 되므로 람다 중간 표현을 생성할 때 모든 타입을 버립니다.

Chris Jenkins: OCaml의 람다 부분에는 타입이 없습니다. 타입 검사와 람다 생성 사이에 버려집니다. 하지만 바이트코드 중간 표현보다 훨씬 더 많은 정보를 가지고 있기 때문에 BuckleScript는 바이트코드보다 람다라는 초기 중간 표현에 연결하는 것을 선택했습니다.

Antonio Monteiro: BuckleScript가 더 이상 사용되지 않는 프로젝트인 이유에 대한 다른 질문에 답하자면, 2020년경에 마케팅을 위해 주로 이름을 바꾸었습니다. BuckleScript 개발자들은 프로젝트를 OCaml에서 벗어나 다른 방향으로 가져가고 싶어했습니다. 그래서 BuckleScript는 들어보셨을지도 모르는 ReScript라는 언어로 이름이 바뀌었습니다. rescript-lang.org에서 확인할 수 있습니다. 훌륭한 언어이고 어떤 의미에서는 BuckleScript의 자연스러운 후속작이라고 할 수 있습니다. 하지만 OCaml로 구축되었음에도 불구하고 OCaml이 전혀 아닙니다. 역사적인 선례가 있지만 JavaScript로 컴파일되는 다른 언어이며 많은 사람들이 사용하고 있습니다.

Chris Jenkins: 그래서 단순히 최종 컴파일 단계가 아니라 완전히 별개의 것이 되었군요.

Antonio Monteiro: 맞습니다. 요즘은 ReScript에 대해 잘 모르지만, 제가 이해하기로는 여전히 동일한 중간 표현에 연결되어 있고 여전히 OCaml 컴파일러를 기반으로 합니다. 기본적으로 OCaml 컴파일러의 포크이지만, JavaScript를 생성합니다. 하지만 완전히 다른 선택을 했습니다. 다른 방향으로 프로젝트를 가져갔습니다. 최근에 ReScript에서 제공한 주요 기능은 커링 또는 부분 적용을 효과적으로 제거한 것입니다. OCaml은 Haskell과 마찬가지로 모든 OCaml 함수가 모든 Haskell 함수와 마찬가지로 자동으로 커링됩니다. 즉, 세 개의 인수를 받아 결과를 반환하는 함수가 있다면 한 개의 인수만 적용할 수 있고, 그러면 결과를 반환하는 두 개의 인수를 받는 함수가 됩니다. 이것은 OCaml이나 Haskell과 같은 언어에서는 잘 작동하지만, ReScript 개발자들은 JavaScript로 컴파일할 때 해당 환경에 있는 함수와 마찬가지로 함수를 사용하는 것이 더 익숙하다고 판단한 것 같습니다. 그래서 이제 ReScript에서는 기본적으로 커링되지 않으며, 이것은 OCaml 프로그램에 큰 변화입니다.

Chris Jenkins: 업계에서는 아직 그런 성전을 치를 준비가 되지 않은 것 같습니다. 모두가 커링이 좋은지 나쁜지에 대한 의견을 갖게 되려면 아마 10년은 더 있어야 할 겁니다. 하지만 OCaml 컴파일러 체인은 매우 플러그형이라는 인상을 받았습니다.

Antonio Monteiro: 맞습니다.

Chris Jenkins: 잘 설계되어 있어서 조각조각 분리할 수 있나요?

Antonio Monteiro: 그 부분은 잘 모르겠습니다. 제가 그런 판단을 내릴 수 있는 사람인지도 모르겠습니다. 적어도 구문 측면에서는 설명드린 대로 구문을 전환할 수 있으므로 매우 플러그형이라고 할 수 있습니다. 사람들에게 익숙한 또 다른 부분은 매크로입니다. OCaml에서는 PPX 또는 전처리기 확장이라고 합니다.

Chris Jenkins: 어떤 종류의 매크로인가요?

Antonio Monteiro: AST 수준의 매크로입니다. 좋은 종류죠. C 전처리기 매크로와 같은 종류는 아닙니다. Rust 수준의 매크로와도 다릅니다. Rust 매크로는 AST를 가져와서 어떤 방식으로든 변환하지만 다른 방식으로 정의되기 때문입니다. Rust 매크로에 대해서는 잘 모릅니다.

Chris Jenkins: Lisp 스타일의 매크로처럼 들리는군요.

Antonio Monteiro: Lisp 스타일의 매크로와 비교하는 것이 타당할 것 같습니다. Lisp는 동형이고 타입이 없으며 AST를 조작하기가 OCaml보다 훨씬 쉽지만, OCaml의 AST는 대수적 데이터 타입과 매우 유사합니다. 그래서 많은 변형, 열거형 또는 케이스가 있습니다. 표면적이 꽤 넓기 때문에 OCaml에서 매크로 또는 PPX를 작성하는 것이 항상 간단한 것은 아닙니다. 어떤 언어 구문, 어떤 구문 구조에 연결할지 결정해야 하고, 모델링하고 수정하여 해당 구문 노드의 새로운 버전을 생성해야 합니다. 또한 기본적으로 매크로의 경우 프로그램에 대한 타입 정보에 액세스할 수 없으며 프로그램의 다른 부분을 쿼리할 수 없습니다. 구문 수준에서만 작동하기 때문입니다.

Chris Jenkins: 죄송합니다. 이 부분이 매우 플러그형이고 이를 돕는 라이브러리가 있다고 말씀드리려고 했습니다. 하지만 다른 부분은 플러그형이 아닌 것 같습니다. 예를 들어, 바이트코드에 연결하려면 바이트코드로 컴파일할 때 프로그램의 최종 출력이기 때문에 작동하지만, 타입 트리에 연결하거나 람다 표현에 연결하려면 컴파일러 포크를 작성해야 할 겁니다.

Antonio Monteiro: 맞습니다.

Chris Jenkins: 그러면 Antonio님의 큰 프로젝트 중 하나인 Melange에 대한 이야기로 이어집니다. Melange는 다른 컴파일러 백엔드를 만들기 위해 연결한 것이죠?

Antonio Monteiro: 맞습니다. 앞서 BuckleScript가 ReScript를 만들기 위해 어떤 의미에서는 OCaml에서 벗어났다고 말씀드렸습니다. 저는 개인적으로 OCaml 에코시스템에 푹 빠져 있었고, 쉽게 놓아줄 수 없었습니다. 그래서 거의 4년 전 오늘, ReScript가 되기 전에 BuckleScript를 포크했습니다. 혼란스러울 수 있으니 다시 한번 말씀드리겠습니다. OCaml과 ReasonML을 JavaScript로 컴파일하는 BuckleScript가 구문과 컴파일을 새로운 방향으로 가져가고 싶어하는 새로운 언어인 ReScript Lang이 되면서, 저는 BuckleScript의 이념을 고수하고 싶었습니다.

Chris Jenkins: 제 생각에는 ReScript보다 OCaml에 더 가깝죠.

Antonio Monteiro: 맞습니다. 그래서 BuckleScript를 포크하고 계속 작업하면서 OCaml 커뮤니티를 위해 더 나은 컴파일러를 만들고 싶었습니다. 다른 관점에서 보면, 예를 들어 JavaScript 개발자인 경우 전체 에코시스템에 익숙하고 npm에서 설치하는 것을 좋아하기 때문에 ReScript를 선택할 가능성이 높습니다. ReScript는 npm 설치로 사용할 수 있고, 새로운 컴파일-투-JS 언어를 자신의 프로그램에서 시험해 볼 수 있습니다. 하지만 OCaml 프로그래머이고 OCaml과 에코시스템에 매우 익숙하며 npm 세계의 모든 최신 도구로 파싱하고 변환할 수 있는 최신 JavaScript를 생성하고 싶다면, 제가 시작한 프로젝트인 Melange를 사용할 겁니다.

Chris Jenkins: 그래서 큰 차이점은 JavaScript 프로그래머가 OCaml에 가까워지고 싶어하는지, 아니면 OCaml 프로그래머가 브라우저로 진출하고 싶어하는지입니다.

Antonio Monteiro: 네, 맞습니다.

Chris Jenkins: 브라우저로 진출하고 싶어하는 일반적인 OCaml 프로그래머에게 필요한 툴체인은 어떤 모습일까요?

Antonio Monteiro: Melange는 BuckleScript가 작동했던 방식과 매우 유사하게 작동합니다. 하지만 우리가 바꾼 한 가지는 OCaml 플랫폼의 나머지 부분과 상호 작용하는 방식입니다. 이것이 요즘 Melange의 가장 큰 장점입니다. Melange는 컴파일러 수준에서 작동합니다. OCaml 컴파일러와 마찬가지로 모든 구문, 모든 추상 구문 트리를 가져올 수 있습니다. 또한 람다 중간 표현에 연결하여 거기에서 아름답고 읽기 쉬운 JavaScript를 생성합니다. 에코시스템과 플랫폼 수준에서는 BuckleScript가 예전에 작동했던 방식과 큰 차이가 있습니다. Melange는 OCaml 플랫폼이라고 하는 것과 통합되어 있습니다. 이것은 OCaml 컴파일러와 에코시스템을 중심으로 작동하도록 설계된 전체 도구 세트를 나타내는 공식 용어입니다. OCaml 플랫폼에는 코드를 빌드하고, 패키지를 가져오고, 편집기에서 편집기 통합(언어 서버 프로토콜 등)을 위한 도구가 있습니다. 자동 문서 생성을 위한 도구도 있고, 지금 당장 생각나지 않는 다른 도구도 있을 겁니다. 하지만 언어를 만드는 것이 어려운 이유 중 하나가 바로 이런 것들입니다. 언어를 다 만들고 스스로에게 칭찬을 하지만, 여전히 패키지 관리자, 빌드 도구 등을 만들어야 합니다.

Chris Jenkins: 맞습니다.

Antonio Monteiro: 이것은 매우 의도적이고 매우 초기 단계의 설계 선택이었습니다. 우리는 근본으로 돌아가서 OCaml에 최대한 가까워지고 싶었습니다. OCaml 플랫폼과 통합하고, OCaml 빌드 시스템인 Dune과 통합할 수 있다면 전체 에코시스템, 모든 도구에 액세스할 수 있을 것입니다. 효과적으로 거인의 어깨 위에 서 있는 것이죠. 우리가 오기 전에 설계되고 계획되고 작성된 모든 도구를 사용할 수 있습니다. BuckleScript가 처음에는 툴체인이 제대로 작동하는 것처럼 보였던 경험으로 돌아갈 수 있습니다.

Chris Jenkins: 그렇습니다. 이제 OCaml 에코시스템의 근본으로 돌아갑니다.

Antonio Monteiro: 네. Melange는 OCaml 빌드 도구인 Dune을 사용하여 프로젝트를 빌드합니다.

Chris Jenkins: 잠깐만요. Dune은 OCaml 테마인가요? 프랭크 허버트의 말장난을 해야 하는 건가요?

Antonio Monteiro: 그럴 수도 있습니다. 솔직히 저는 Dune 전설에 대해 잘 모릅니다. 커뮤니티 멤버가 Melange라는 단어를 생각해 냈는데, 저는 매우 잘 어울린다고 생각했습니다. Melange는 프랑스어로 혼합물을 의미하며, Melange는 OCaml에서 JavaScript를 생성하기 위해 여러 가지 도구가 혼합된 것입니다. 그래서 완벽하게 어울린다고 생각했고, 그대로 사용했습니다. Melange는 OCaml 빌드 도구인 Dune을 사용하여 프로젝트를 빌드합니다. OCaml 패키지 관리자인 opam에서 패키지와 라이브러리를 가져오고, OCaml LSP, OCaml 언어 서버 프로토콜, 타입 완성, 정보, 진단 기능을 제공하는 라이브러리인 Merlin을 사용합니다. odoc을 사용하여 문서를 생성하고, dune-release라는 도구를 사용하여 Melange 프로젝트를 패키징하고 OCaml 패키지 관리자인 opam에 게시할 수 있습니다. 9월에 베를린에서 열리는 Fun OCaml이라는 새로운 컨퍼런스에서 Melange 도구에 대해 발표할 예정입니다. 정말 기대됩니다. 여기서 우리가 이야기하고 있는 내용을 다시 한번 강조하고 Melange를 모든 도구가 하나로 모이는 통합된 방식으로 소개할 수 있을 것 같습니다.

Chris Jenkins: 프런트엔드와 백엔드에서 코드를 공유하는 웹 애플리케이션을 만들 때 정말 좋은 경험을 할 수 있는 언어가 두 개, 아니 이제 세 개가 떠오릅니다. 틈새시장이지만 제가 좋아하는 PureScript, 새롭지만 전체 에코시스템이 매우 훌륭한 Gleam이 있습니다. 이제 OCaml도 이 목록에 추가할 수 있나요? 진정한 브라우저-서버 언어인가요?

Antonio Monteiro: 네, 그게 목표입니다. 확실히 목표입니다. 저는 그 목록에 Closure와 ClosureScript도 추가할 겁니다. Closure와 ClosureScript도 그런 목표를 가지고 있으며, 저는 Closure와 ClosureScript를 많이 사용해 보았습니다. 이전 직장에서 사용했는데, 정말 잘 작동했습니다. 하지만 주제로 돌아가서 PureScript는 Haskell과 함께 사용하시나요?

Chris Jenkins: 아니요. PureScript는 모두 Node로 컴파일되므로 프런트엔드에서는 JavaScript, 백엔드에서는 Node를 사용합니다. 표면 구문은 모두 Haskell이지만 AST 구현은 기본적으로 JavaScript 엔진입니다. Gleam도 마찬가지인가요?

Antonio Monteiro: Gleam에는 다른 백엔드도 있는 것으로 알고 있습니다. JavaScript로 컴파일하거나 Erlang 가상 머신인 BEAM으로 컴파일할 수 있습니다.

Chris Jenkins: JavaScript-투-JavaScript는 쉬운 모드이기 때문에 그런 질문을 드렸습니다. 요즘은 JavaScript나 TypeScript를 작성하고 프런트엔드와 백엔드를 모두 TypeScript나 JavaScript로 만들 수 있습니다. PureScript를 Node와 프런트엔드의 JavaScript로 컴파일할 수 있다고 말씀하신 것처럼요. 제가 상상했던 것은 완전히 다른 런타임에서 동일한 언어를 실행하고 서로 통신하는 것입니다. ClosureScript는 JavaScript로 컴파일되고 Closure는 JVM에서 실행됩니다.

Antonio Monteiro: OCaml도 마찬가지입니다. 이것이 제가 목표라고 말한 것입니다. OCaml을 Melange를 통해 JavaScript로 컴파일할 수 있습니다. 다시 말씀드리지만, 쉬운 모드는 서버에서 Node.js로 Melange를 컴파일하는 것입니다. 이것도 작동하지만, 우리가 정말로 노력하고 있고 기대하고 있는 것은 동일한 코드베이스를 사용하는 것입니다. 적어도 공유되는 부분은요. 타입은 백엔드와 프런트엔드에서 대부분 공유되어야 직렬화와 역직렬화를 쉽게 할 수 있습니다. 일부는 Melange를 사용하여 JavaScript로 컴파일되고, 백엔드는 OCaml을 사용하여 네이티브 코드로 컴파일되며, 동일한 코드베이스를 실행하고 서로 통신합니다.

Chris Jenkins: 어떻게 되나요? 코드의 일부를 JavaScript로 컴파일할 경우 이렇게 하라고 표시하나요?

Antonio Monteiro: 맞습니다. 언어 지시문과 같습니다. 아직 그런 지시문은 없고, 우리가 작업하고 있는 것 중 하나입니다. 전처리기 확장(PPX)을 사용하면 작동할 수 있을 것 같습니다. 기본적으로 언어에 대한 확장이므로 지시문을 추가할 수 있습니다. 빌드 시스템의 지원도 필요합니다. 이것은 아직 진행 중인 작업이지만, ahrefs에서 하고 있는 흥미로운 작업 중 하나입니다. ahrefs는 처음부터 Melange의 주요 후원사였으며 지금도 그렇습니다. 그래서 오늘 함께 언급하고 싶었습니다. ahrefs는 검색 엔진 최적화 분야의 대기업이며, 모든 애플리케이션을 OCaml로 개발합니다. 프런트엔드는 Melange로 컴파일됩니다. 최근에 ahrefs에서 하고 있는 일은 기본적으로 reactjs 서버 측 렌더링을 OCaml로 다시 구현하는 것입니다. 새로운 React 서버 구성 요소를 구현하고 있는데, 효과적으로 OCaml의 RPC 프로토콜입니다. 그래서 어떤 의미에서는 목표일 뿐만 아니라 이미 현실이 된 것입니다. ahrefs 웹 페이지와 웹 애플리케이션 중 일부는 Melange를 통해 컴파일된 reactjs가 브라우저에서 작동하기 전에 서버 측 렌더링 프로세스를 거칩니다. 이 프로세스는 프런트엔드에서 렌더링되는 것과 동일한 코드를 사용합니다. 또 다른 인터프리터라고 할 수 있습니다. HTML로 컴파일하여 브라우저에 전송합니다.

Chris Jenkins: 그러니까 코드가 브라우저에서 실행되어 HTML을 생성하거나, JavaScript를 전송하여 브라우저에서 실행되어 HTML을 생성하거나, 서버에서 로컬로 실행하여 HTML 부분만 전송할 수 있다는 말씀이죠.

Antonio Monteiro: 맞습니다. HTML 부분을 전송하고 JavaScript도 전송하지만, reactjs가 이를 처리하고 이미 페이지에 있는 JavaScript에 이벤트 핸들러를 설치합니다. 이것을 하이드레이션이라고 합니다.

Chris Jenkins: 왜 좋은 건가요?

Antonio Monteiro: 좋은 이유는 역사적으로 크롤링 엔진이 웹 페이지의 JavaScript를 실행하지 않았기 때문입니다. 오늘날은 어떤지 잘 모르겠지만, 여전히 그렇다고 생각합니다. 모든 웹 애플리케이션이 reactjs로 작성된 세상에서는 웹사이트의 HTML을 로드할 때 가장 먼저 표시되는 것은 스크립트를 로드하는 컨테이너 div입니다. 스크립트 태그가 있는 것이죠. 반면에 이 세상에서는 가장 먼저 전체 HTML 페이지가 표시되고, 그 다음에 이벤트 핸들러를 설치하는 스크립트 태그가 표시됩니다. 검색 엔진 최적화 회사에게 이것이 얼마나 중요한 주제인지 상상할 수 있을 겁니다.

Chris Jenkins: 네, 옛날에 크롤러가 빈 페이지로 표시하지 않도록 정적 HTML 버전의 페이지를 제공해야 했던 프로젝트에 참여한 적이 있습니다.

Antonio Monteiro: 맞습니다. 바로 그 문제를 해결하는 것입니다. 그러면 개발자는 그런 것에 대해 생각하지 않고 react를 작성하는 것처럼 전체 작업을 할 수 있나요?

Antonio Monteiro: 네, 맞습니다. 해결되는 또 다른 문제는 로딩 지표입니다. FCP(First Contentful Paint)였던가요? HTML을 브라우저에 전송하면 페이지가 영원히 로딩되는 것처럼 보이지 않습니다. 이미 구조가 있고, JavaScript가 이를 처리할 수 있기 때문입니다. 반면에 다른 경우에는 JavaScript를 다운로드하고, 엔진이 JavaScript를 파싱하고, reactjs를 실행하고, 프런트엔드에서 HTML(DOM)을 생성하는 데 시간이 걸립니다. 그래서 일종의 해킹처럼 이러한 모든 단계를 건너뛰고, 여전히 모든 단계를 수행하지만 사용자가 읽을 수 있는 콘텐츠가 이미 페이지에 있습니다.

Chris Jenkins: 사용자에게 HTML을 먼저 전송하면 사용자가 보는 동안 로딩 시간을 1초 더 벌 수 있습니다.

Antonio Monteiro: 맞습니다.

Chris Jenkins: 이해가 됩니다. 전체 에코시스템이 어떻게 맞물리는지 알겠습니다. OCaml 내부 표현을 JavaScript 실행 엔진으로 작성하는 작업이 왜 어려울까요? 얼마나 다른가요?

Antonio Monteiro: 몇 가지 이유가 있습니다. 최상의 경우에는 그렇게 어려운 변환이 아닙니다. 핵심 OCaml 언어만 사용한다면 람다는 이미 코드 생성에 최적화되어 있습니다. 중복 제거가 이미 많이 되어 있고, 참조가 이미 많이 해결되어 있으며, 람다에서 많은 정보를 얻을 수 있습니다. 하지만 얻을 수 없는 정보도 있습니다. 한 가지 예는 OCaml 메모리 모델이 JavaScript 프로그램의 모습과 조금 다르다는 것입니다. 예를 들어 레코드가 있는 경우, 레코드는 키가 컴파일 타임에 정적이라는 것을 제외하면 딕셔너리와 같은 것입니다. OCaml의 레코드에서 JavaScript 객체를 생성하고 싶을 겁니다.

Chris Jenkins: 당연하죠. 키-값 쌍이니까요.

Antonio Monteiro: OCaml 컴파일러가 타입 검사와 람다 생성 사이에서 생략하기 때문에 우리가 변경해야 했던 것은 키 이름에 대한 정보를 보존하는 것이었습니다. OCaml 메모리 모델에서 레코드가 있고 타입에 액세스할 수 있는 경우(예: a, b, c 속성이 있는 경우) 메모리에 순서대로 배치됩니다. 따라서 첫 번째 블록은 a, 두 번째 블록은 b, 세 번째 블록은 c라는 것을 알 수 있습니다. 따라서 이름을 유지할 필요가 없습니다. 키 이름을 유지할 필요가 없습니다.

Chris Jenkins: 맞습니다.

Antonio Monteiro: 이제는 소스-머신 변환을 하는 것이 아니라 소스-소스 변환을 하고 있습니다. 소스-소스 변환을 할 때는 소스-머신 변환을 할 때는 사용할 수 없는 많은 정보를 보존해야 합니다. 이것이 우리가 처음에 직면했던 장벽 중 하나입니다. 핵심 언어는 컴파일하기 쉽다고 말씀드렸지만, 암시적으로 말씀드린 것은 OCaml 언어에는 확장 기능이 많고 이러한 확장 기능을 컴파일하는 방법이 명확하지 않다는 것입니다. 예를 들어 모듈 시스템의 경우, OCaml의 모듈 시스템은 정말 흥미롭습니다. 모든 파일이 모듈이고, 모듈은 값의 집합이라고 생각할 수 있습니다. 다른 언어와 마찬가지로 모든 파일은 값 세트를 내보냅니다. 이것은 대부분의 값이 함수 또는 값을 가리키는 이름이라는 점을 감안할 때 컴파일하기가 꽤 간단하다고 생각합니다. 하지만 모든 모듈에는 하위 모듈이 있을 수 있습니다. 따라서 a.ml이라는 파일에는 b라는 모듈이 있을 수 있고, b는 이러한 값의 또 다른 집합이며, 하나는 파일이지만 모듈로 취급할 수 있다는 점에서 서로 바꿔 사용할 수 있습니다. OCaml 언어에서 일급 시민이기 때문입니다. 모듈 시스템은 OCaml의 값 언어와 다르지만, 서로 변환할 수 있고 모듈을 함수의 인수로 전달할 수 있습니다. 어떤 의미에서는 모듈을 리프팅하고 언리프팅할 수 있습니다.

Chris Jenkins: 모듈에서 실행할 함수의 예를 들어 주시겠어요?

Antonio Monteiro: 예를 들어 비동기 런타임이 있다고 가정해 보겠습니다. 동일한 시그니처를 갖지만 구현이 다른 비동기 런타임입니다. 따라서 백엔드를 다르게 할 수 있습니다. OCaml 용어로는 전략 패턴이라고 합니다. Gang of Four를 언급하려는 것은 아닙니다. 먼저 모듈 시그니처를 정의하는 것으로 시작합니다. 이 경우에는 이 런타임에서 Future의 타입은 무엇이며, 모나드 용어로 한다면 bind 함수의 타입은 무엇일까요? 타입은 익명으로 유지할 수 있는 타입 T이고, bind는 T에서 a를 받아 b의 t 또는 t의 b를 생성하는 함수로의 일반적인 타입일 겁니다. 결과도 t의 b입니다. 이것은 일련의 Future를 연결할 수 있게 해주는 함수입니다.

Chris Jenkins: 맞습니다. 이것은 모나드 bind이죠.

Antonio Monteiro: 맞습니다. 이 모나드 시그니처를 전달하고 싶고 다른 방식으로 구현하고 싶다고 가정해 보겠습니다. 비동기 런타임에 대해 이야기하고 있지만, 아시다시피 이것은 훨씬 더 일반화할 수 있습니다. 기본적으로 이 시그니처를 가진 모듈을 받는 함수를 정의하고 모든 호출 사이트에서 고유한 모듈 구현을 정의하고 이러한 함수에 일급 모듈(OCaml에서 이렇게 부릅니다)을 전달할 수 있습니다.

Chris Jenkins: 그러면 함수 내에서 전달받은 모듈의 bind 함수를 사용한다는 말씀인가요?

Antonio Monteiro: 맞습니다. 이 함수 집합을 구현하는 모듈을 제공하면 모듈의 계약을 준수하는 한 누가 구현했는지는 신경 쓰지 않고 사용할 수 있습니다. 인터페이스와 비슷합니다.

Antonio Monteiro: 인터페이스와 비슷하고, "Antonio, 왜 이렇게 복잡하게 해야 하나요? 레코드를 전달하면 되잖아요?"라고 물어볼 수도 있습니다. 경우에 따라서는 그렇습니다. 때로는 모듈로 추상화하는 것이 더 쉽습니다.

Chris Jenkins: 폴리모피즘에 따라 다르겠죠? 여기서는 다루지 않겠습니다.

Antonio Monteiro: 맞습니다. 이것은 JavaScript로 컴파일할 때 어려운 과제입니다. OCaml 모듈 시스템에 대한 긴 이야기는 제쳐두고, 모두가 한번 시도해 보시길 권합니다. 이러한 언어 확장 기능 중 일부는 컴파일하기가 다른 것보다 더 어렵습니다. 한 가지 예는 모듈이지만, 솔직히 JavaScript에서는 모듈을 컴파일하기가 매우 쉽습니다. 억지로 보면 JavaScript 모듈과 OCaml 모듈의 표현이 비슷하기 때문입니다. 적어도 CommonJS 패러다임에서는 JavaScript 모듈을 가져오면 값의 집합인 객체가 됩니다. 키-값 쌍이 있는 객체이고, 키는 이름이고 값은 값입니다.

Chris Jenkins: 네.

Antonio Monteiro: 그래서 파일 내에 있는 하위 모듈을 동일한 형태의 JavaScript 객체로 컴파일하면 서로 바꿔 사용할 수 있다고 생각했습니다.

Chris Jenkins: 이런 프로젝트에서는 OCaml의 것이 JavaScript에서 무엇과 같은지 파악하는 것이 중요합니다. 이것은 큰 과제이고 큰 부분을 차지합니다. 이 언어에서 값의 표현이 다른 언어의 표현에 어떻게 매핑되는지, 그리고 JavaScript에서 익숙하고 성능이 좋고 코드 생성을 통해 쉽게 조작할 수 있는 구조의 인체 공학적 버전에 어떻게 매핑되는지 알아내야 합니다. 항상 가능했나요? 아니면 OCaml 기능을 지원하지 않거나 특히 관용적인 코드를 생성하지 않기로 결정해야 했던 적이 있나요?

Antonio Monteiro: 항상 가능했던 것은 아닙니다. 특히 최근 OCaml 컴파일러에는 현재 지원하지 않는 기능이 있습니다. 예를 들어 OCaml 컴파일러의 가장 최근 주요 릴리스인 OCaml 5에는 공유 메모리 병렬 처리와 대수적 효과 핸들러라는 두 가지 주요 기능이 도입되었습니다. JavaScript는 단일 스레드 언어이기 때문에 OCaml의 새로운 OCaml 런타임의 멀티 코어 특성을 지원할 수 없습니다.

Chris Jenkins: 큰 제약이군요.

Antonio Monteiro: 또 다른 하나는 효과 핸들러인데, 현재 연구 중인 기능이고 지원할 수 있을 것 같지만 아직은 지원하지 못했습니다. 자세히 설명하자면, 효과 핸들러는 효과적으로 호출 스택을 되감고, OCaml 백엔드에서 구현하는 방식은 Go가 런타임에서 하는 것처럼 스택 전환을 하는 것입니다.

Chris Jenkins: 잘 모르겠습니다. 예외를 생각해 보세요.

Antonio Monteiro: 효과 핸들러는 어떤 의미에서는 재개 가능한 예외입니다. 호출 스택을 되감는 무언가를 던질 수 있지만, 작업을 완료한 후에는 이전 위치로 돌아갈 수 있습니다. 이를 수행하는 방법은 여러 가지가 있지만, 그 중 하나는 스택 전환이고 다른 하나는 연속 전달 스타일로 호출하는 것입니다. 이것들은 Melange에서 상당히 큰 과제입니다. 첫 번째 과제는 JavaScript에서 스택 전환을 할 수 없다는 것입니다. 그 수준의 액세스 권한이 없기 때문입니다. goto도 없고 점프도 할 수 없습니다. 두 번째 과제는 연속 전달 스타일로 구현할 수 있지만, JavaScript 코드를 생성할 때 정의하는 모든 함수에 새로운 인수를 추가해야 한다는 것입니다.

Chris Jenkins: 이것은 Melange가 JavaScript로 코드를 컴파일하는 방식에 대한 매우 큰 가정, 매우 큰 차이를 깨뜨립니다. 현재는 OCaml과 JavaScript 사이의 호출 규칙이 동일하므로 b와 c라는 인수를 받는 함수 let a를 구문적으로 볼 수 있고 JavaScript에서 b와 c라는 인수를 사용하여 a를 호출할 수 있다는 것을 보장할 수 있습니다.

Antonio Monteiro: 그래서 출력 코드가 읽기 쉽게 보이기를 원할 뿐만 아니라 다른 것처럼 사용할 수 있기를 원합니다. OCaml 코드에서 JavaScript로 직관을 그대로 가져올 수 있기를 원하며, 우리는 이를 최대한 보존하고 싶습니다.

Antonio Monteiro: 맞습니다. 모든 것을 연속 전달로 전환하면 이러한 장점이 완전히 사라집니다.

Chris Jenkins: 그렇습니다. 이것은 OCaml에서 JavaScript로 컴파일러를 구현하는 또 다른 과제로 이어집니다. 바로 경계를 어떻게 처리할 것인가입니다. 경계는 항상 가장 흥미로운 부분입니다. OCaml은 어디에서 끝나고 JavaScript는 어디에서 시작될까요? npm 에코시스템에 있는 라이브러리(JavaScript로만 작성된 라이브러리)를 OCaml 프로그램에서 어떻게 호출할 수 있을까요? 반대로 Melange로 컴파일한 것을 JavaScript에서 어떻게 호출할 수 있을까요? 네이티브의 경우 Melange가 동적 또는 정적 라이브러리를 생성하고 다른 아티팩트에 연결한다고 생각하면 됩니다. JavaScript 개발자를 위해 npm에 패키지를 게시하고 싶지만, JavaScript로 작성하고 싶지는 않습니다.

Antonio Monteiro: OCaml로 작성하고 싶고, Melange를 통해 실행하고, npm에 게시하고 모든 사람에게 "JavaScript에서 이 패키지를 호출하는 방법은 다음과 같습니다."라고 말하고 싶습니다. 제가 좋아하는 언어로 작성했다는 것을 굳이 밝히고 싶지는 않습니다.

Chris Jenkins: 네. 이것은 또 다른 과제입니다. 앞서 커링에 대해 조금 이야기했는데, 커링은 이러한 경우에 상당히 큰 과제입니다. 컴파일 단계에서 컴파일러 최적화를 통해 어느 정도 해결할 수 있지만, 특히 함수가 서로 전달되는 모든 동적 경우에는 그럴 수 없습니다. 따라서 Melange를 JavaScript로 컴파일하거나 OCaml을 Melange를 사용하여 JavaScript로 컴파일할 때는 커링을 위한 런타임이 필요합니다.

Chris Jenkins: 잠깐만요. OCaml에는 네이티브 커링이 있고 JavaScript에서 이를 처리하기 위해 추가 런타임을 만들어야 한다는 말씀인가요?

Antonio Monteiro: 예를 들어 리스트의 모든 요소에 대해 매핑하는 list.map을 생각해 보세요. OCaml에서 list.map의 시그니처는 함수, 리스트, 결과입니다.

Chris Jenkins: 네.

Antonio Monteiro: 하지만 함수형 프로그램에서 매우 일반적인 것처럼 list.map 함수를 부분적으로 적용할 수 있습니다. 첫 번째 인수인 콜백만 전달하면 모든 리스트를 받아 해당 변환을 적용할 수 있는 재사용 가능한 함수가 됩니다.

Chris Jenkins: 네.

Antonio Monteiro: JavaScript에서는 이를 어떻게 표현할 수 있을까요? JavaScript에서 list.map은 두 개의 인수(콜백과 리스트)를 받아 새로운 리스트를 반환하는 함수입니다. 인수를 하나만 전달하면 함수가 완전히 적용되고 두 번째 인수는 undefined가 됩니다.

Chris Jenkins: 그래서 JavaScript에서 그렇게 하려면 두 개의 인수를 받는 함수를 작성하고, 아니, 인수를 하나 받아서 다음 인수를 기다리는 새 함수를 반환하는 함수를 작성해야 합니다. 커링을 다시 발명해야 합니다.

Antonio Monteiro: 앞서 말씀드린 것처럼 가능한 한 전체 적용을 하려고 노력합니다. 특히 컴파일 타임에 알아낼 수 있는 경우에는 인수를 하나 적용하고 함수를 가져와서 다시 적용하는 것보다 성능이 좋기 때문입니다. 하지만 모든 경우에 그럴 수는 없기 때문에 런타임도 제공합니다. 사용자가 걱정할 필요는 없지만, 경우에 따라 Melange는 이를 처리하는 Curry 런타임을 호출합니다.

Chris Jenkins: 일반적인 경우에는 원본 소스 코드에서 커링되지 않은 함수가 무엇이었는지 다시 파악하는 것이 거의 불가능하다고 생각했기 때문입니다.

Antonio Monteiro: 경우에 따라 다릅니다.

Chris Jenkins: 이 팟캐스트의 비공식 모토는 "경우에 따라 다릅니다"입니다. 흥미로운 질문은 항상 그렇습니다.

Antonio Monteiro: 이러한 어려움에도 불구하고, 저는 이 질문을 해야 할 것 같습니다. 다른 길을 갈 수도 있었습니다. OCaml을 OCaml 바이트코드로 컴파일하는 방법입니다. OVM이라고 하나요?

Chris Jenkins: 그냥 추측해서 OVM이라고 했습니다. JVM과 같은 건가요? OCaml용으로요? OVM이라고 불리는지는 모르겠습니다. 들어본 적이 없습니다. 제가 만들어 낸 말입니다. 바이너리 이름은 ocamlrun이라고 생각합니다.

Antonio Monteiro: 네, ocamlrun입니다. VM이 뭐라고 불리는지는 모르겠습니다. 그 지점에서 개입하여 OCaml 바이트코드를 생성하는 대신 WASM을 생성한다고 하면 이러한 가독성 문제가 줄어들지 않을까요?

Chris Jenkins: 흥미롭네요. 그러니까 OCaml용으로 WASM을 생성하는 새로운 컴파일러 백엔드를 만든다는 말씀이죠? 그러면 가독성에 대해 걱정할 필요가 없습니다. 아무도 신경 쓰지 않으니까요.

Antonio Monteiro: 네, 맞습니다. 훌륭한 질문이고 좋은 지적입니다. 몇 가지 프로젝트가 진행 중인 것으로 알고 있습니다. 에코시스템이나 플레이어에 대해서는 잘 모르지만, 현재 OCaml에서 WASM을 생성하는 프로젝트가 적어도 두세 개는 경쟁하고 있는 것으로 알고 있습니다. 이름은 말씀드릴 수 없습니다. 최신 정보를 파악하지 못했습니다.

Chris Jenkins: 괜찮습니다. 하지만 그런 프로젝트가 있다는 것은 알겠습니다. 구체적인 질문에 답하자면, 아직은 모든 사람에게 WASM이 바람직한 세상은 아니라고 생각합니다. WASM에는 GC가 없고 OCaml은 GC 언어라는 기술적 제약은 무시하더라도 말입니다. 최근에 WASM에 GC를 추가하는 제안이 나왔거나 나오려고 하는 것 같습니다.

Chris Jenkins: 그렇지 않으면 WASM에서 먼저 가비지 수집기를 구현해야 합니다.

Antonio Monteiro: 맞습니다. 그 방향으로 나아간 프로젝트가 몇 개 있습니다. 하지만 다른 이유, 적어도 제 사용 사례에서는 더 강력한 이유는 사람들이 WASM을 직접 사용하지 않는다는 것입니다. 제가 이해하기로는 많은 코드가 여전히... 아니, 이렇게 말씀드리겠습니다. WASM은 일종의 블랙박스를 생성합니다. 원래는 렌더링 엔진이나 게임과 같이 고성능 프로그램을 작성하고 최소한의 수정으로 브라우저에서 실행할 수 있도록 하기 위한 것이었습니다. WASM의 FFI(외부 함수 인터페이스)가 어떤 모습인지, 즉 WASM에서 JavaScript 함수를 어떻게 호출하는지, WASM에서 JavaScript로 인터페이스를 어떻게 노출하는지 잘 모르겠습니다. 제가 무지해서 그럴 수도 있습니다. 아마 이러한 문제는 모두 해결되었을 텐데 제가 모르는 것일 수도 있습니다. 아니면 아직 완전히 해결되지 않았을 수도 있습니다. 잘 모르겠습니다. 하지만 제 생각에는 WASM은 근처에 있는 별도의 시민에게 RPC를 수행하는 것과 비슷합니다. 샌드박싱 요구 사항 때문에 그럴듯합니다. Melange와 모든 컴파일-투-JS를 사용하면 npm에 있는 모든 라이브러리에 액세스할 수 있고 동일한 프로세스, 동일한 스레드에서 실행되는 코드를 사용하여 네이티브 방식으로 상호 작용할 수 있습니다. 이것이 제가 이해하는 트레이드오프입니다.

Chris Jenkins: 실제 JavaScript 출력에 대한 시장은 여전히 매우 크고 오랫동안 유지될 것 같습니다.

Antonio Monteiro: 저도 그렇게 생각합니다. WASM에서 reactjs 애플리케이션을 작성하는 방법이 궁금합니다. 본 적이 없고, 할 수 있을지도 모르겠습니다. ahrefs와 같이 OCaml에서 reactjs 애플리케이션을 개발하고 reactjs, reason-react를 사용하는 특정 사용 사례의 경우, 이러한 시나리오에서 어떻게 지원되는지 보고 싶습니다.

Chris Jenkins: 다시 현실로 돌아와서, react를 작성하고 싶어하는 OCaml 개발자라면 오늘 무엇을 해야 하나요? react와 비슷한 OCaml 라이브러리가 있나요? 아니면 실제 react에 대한 바인딩이 있나요? 어떤 모습인가요?

Antonio Monteiro: 이것은 경계에 대해 이야기할 때 조금 언급했던 내용입니다. 한쪽에서 다른 쪽을 호출하고 싶을 때 어떻게 되는지 말입니다. 에피소드 초반에 OCaml 자체가 네이티브로 컴파일할 때 C에 대한 흥미로운 인터럽트 스토리를 가지고 있다고 말씀드렸습니다. 에코시스템에서 사용할 수 있는 라이브러리가 없다면 C 라이브러리에 대한 바인딩을 작성하고 호출할 수 있습니다. Melange에서는 실제로 동일한 메커니즘을 사용하지만 C 대신 JavaScript를 호출합니다. 작동 방식은 호출하려는 함수의 이름을 정의하고 OCaml 용어로 함수의 시그니처가 어떤 모습인지 정의합니다. 이 부분은 안전하지 않습니다. JavaScript는 매우 동적이기 때문에 추측해야 하기 때문입니다.

Chris Jenkins: 네, JavaScript 함수의 타입 시그니처를 올바르게 파악하는 것은 사용자의 책임입니다.

Antonio Monteiro: 사용자의 책임입니다. 그런 다음 몇 가지 속성을 해석하는 PPX를 추가하여 JavaScript의 모든 구문 구조(새 객체를 호출하는 방법, 프로토타입에 무언가를 정의하는 방법, 클래스를 정의하는 방법 등)를 생성할 수 있도록 했습니다. 이것이 reactjs에 대해 우리가 취한 접근 방식입니다. ReasonReact라는 라이브러리가 있는데, 이 라이브러리는 Melange보다 먼저 나왔습니다. ReasonML 프로젝트가 시작되었을 때, 아직 BuckleScript를 사용하고 있을 때 작성되었습니다. 우리는 ReasonReact를 가져와서 사용했습니다. ReasonReact에는 ReasonML JSX(언어에 내장되어 있음)를 해석하고 react JSX 또는 createElement 호출을 생성하는 매우 훌륭한 PPX(전처리기 확장)가 있습니다.

Chris Jenkins: 그러니까 OCaml을 작성하고 JSX를 통해 HTML 태그를 포함할 수 있다는 말씀인가요?

Antonio Monteiro: ReasonML을 작성하는 경우에만 가능합니다. ReasonML은 JSX를 지원합니다. OCaml의 대체 구문이죠.

Chris Jenkins: 맞습니다. Facebook에서 reactjs 프로그램을 작성할 목적으로 개발되었기 때문에 처음부터 JSX가 포함되었습니다. 큰 장점이죠.

Chris Jenkins: OCaml을 작성하고 있지만 JavaScript와 JSX와 매우 유사하게 보이고 JavaScript로 출력됩니다.

Antonio Monteiro: 맞습니다. ReasonML의 JSX는 재사용 가능합니다. 즉, 일반화할 수 있습니다. 일반적으로 사람들은 JSX를 사용하여 reactjs 요소를 브라우저로 출력합니다. 하지만 이것이 ReasonML JSX의 유일한 사용 사례는 아닙니다. 예를 들어 JSX를 사용하여 태그를 지정하는 고유한 pretty printer 정의를 상상할 수 있습니다. JSX로 작성할 수 있는 모든 내부 DSL(도메인 특정 언어)은 ReasonML로 작성할 수 있습니다. 런타임과 변환도 작성해야 하지만요.

Chris Jenkins: 그러니까 일반화할 수 있다는 말씀이군요. OCaml이 어디에 있는지 궁금할 정도입니다. 이 스택에서는 표면 아래에 있는 것 같습니다.

Antonio Monteiro: 네, 표면 아래에 있습니다. 아마도 AST 수준에만 있을 겁니다. 그 대가로 고급 컴파일러인 OCaml 컴파일러와 서버 측에서 Reason을 사용하고 싶을 때 사용할 수 있는 전체 백엔드 에코시스템을 얻게 됩니다.

Chris Jenkins: 백엔드의 경우, 백엔드에서 OCaml로 작성한다면 우리가 그리고 있는 시나리오에서는 OCaml이 어디에나 있습니다. Melange의 경우, 시나리오의 Melange 부분에서는 OCaml이 주로 도구에만 있다고 말씀드리겠습니다. 표면은 JavaScript와 매우 유사하게 보이고 실행되는 것은 JavaScript입니다.

Chris Jenkins: 그러니까 브라우저를 원하는 OCaml 개발자와 OCaml을 원하는 JavaScript 개발자 사이의 경계를 여전히 모호하게 하고 있는 것 같습니다.

Antonio Monteiro: 맞습니다. 저는 그 경계를 모호하게 하고 있습니다. 저는 두 가지 모두에 해당하기 때문입니다. 때로는 한쪽에서 오는 사용 사례가 필요하고 때로는 다른 쪽에서 오는 사용 사례가 필요합니다.

Chris Jenkins: 네, 이해합니다. 제 생각에는 좋은 일입니다. 다시 한 걸음 물러서서 말씀드리겠습니다. Antonio님은 이 모든 작업을 하고 있지만, 작업을 하지 않을 때는 이것이 Antonio님에게 무엇을 해줄까요? 어떻게 활용하고 있나요?

Antonio Monteiro: 여기저기 몇 가지 앱이 있습니다. 사실 이건 웃긴 이야기인데, Melange를 작성하고 관련 도구를 작성하게 된 이유는 제가 사용하고 싶었기 때문입니다. 제가 직접 애플리케이션을 작성하고 브라우저에서 코드를 제공하기 위해 존재하는 무언가를 원했습니다. 이것이 JavaScript를 작성하고 브라우저에서 코드를 제공하는 제가 선호하는 방법이기 때문입니다. 하지만 실제로는 컴파일러와 관련 도구를 작성하는 데 시간을 대부분 보내고, 제 애플리케이션을 작성할 시간은 거의 없었습니다.

Chris Jenkins: 익숙한 이야기입니다.

Antonio Monteiro: 네, 여기저기 몇 가지를 작성했습니다. 공개되지 않은 개인 애플리케이션이 몇 개 있고, Melange로 작업 중인 것도 있습니다. 컴파일러 테스트 또는 새로운 컴파일러 도구를 테스트하기 위해 Melange 애플리케이션을 자주 작성합니다. 하지만 Melange 플레이그라운드 외에는 공개된 것이 없습니다. Melange 플레이그라운드는 melange.playground라고 생각합니다. 온라인 플레이그라운드에서 왼쪽 창에 OCaml을 작성하고 오른쪽 창에 생성된 JavaScript를 볼 수 있습니다.

Chris Jenkins: 소스 코드를 서버로 전송하여 컴파일하나요? 아니면 브라우저에서 모두 처리되나요?

Antonio Monteiro: 브라우저에서 모두 처리됩니다. 여기서 제가 프랑켄슈타인 박사라고 할 수 있을 것 같습니다. 괴물을 만들었죠. 실제로 하는 일은 불행히도 Melange는 아직 자체 호스팅되지 않기 때문에 JS of OCaml(OCaml 에코시스템의 또 다른 플레이어)을 사용하여 Melange를 JavaScript로 컴파일합니다. 그러면 Melange 컴파일러라는 큰 코드 묶음이 생기고, 이를 일종의 블랙박스로 취급합니다. 이 블랙박스에는 OCaml 또는 ReasonML을 입력하고 Melange로 컴파일된 JavaScript를 출력할 수 있는 인터페이스가 있습니다. 그런 다음 Melange 웹 애플리케이션을 그 주위에 놓습니다.

Chris Jenkins: 오르간과 같군요.

Antonio Monteiro: [웃음]

Chris Jenkins: 다시 한번 말씀해 주세요. JS of OCaml을 사용하여 Melange 컴파일러를 JavaScript로 컴파일하는 이유가 무엇인가요? 이 질문을 정확하게 표현하기가 어렵습니다. 너무 메타적이기 때문입니다. JS of OCaml을 사용하여 Melange 컴파일러를 JavaScript로 컴파일합니다. 맞나요?

Antonio Monteiro: 네, 맞습니다.

Chris Jenkins: 왜 그렇게 하나요? JS of OCaml 컴파일러의 단점이 무엇이기에 Melange를 작성하고 싶어지나요?

Antonio Monteiro: 좋은 질문입니다. Melange가 존재하는 이유 중 하나는 JS of OCaml이 우리의 사용 사례에 충분하지 않기 때문입니다. 몇 가지 이유가 있습니다. 첫 번째 이유는 앞서 말씀드린 것처럼 Melange는 람다 계층(람다 중간 표현)에 연결되지만, JS of OCaml은 OCaml 바이트코드를 가져와서 컴파일 타임에 해석하여 JavaScript를 생성합니다. 람다 표현에 있는 모든 정보가 없으면 몇 가지 트레이드오프를 해야 합니다. 바이트코드와 람다 표현 사이에 정보가 손실됩니다.

Chris Jenkins: 정보가 버려집니다.

Antonio Monteiro: 맞습니다. Melange를 통해 컴파일할 때 OCaml 구조를 JavaScript에서 어떻게 표현하는지, 생성된 코드의 가독성에 어떤 영향을 미치는지, JavaScript를 생성하기 위해 사용할 수 있는 다른 구조에 대해 많이 이야기했습니다. 그 중 하나는 레코드 예제입니다. 키 이름에 대한 정보는 보존되지 않습니다. 예를 들어 JS of OCaml을 사용하는 경우에는 레코드를 JavaScript 객체로 표현할 수 없습니다. JS of OCaml을 사용할 때는 주로 OCaml 구조를 JavaScript에서 어떻게 표현하는지, 그리고 모든 정보가 없는 경우 성능에 어떤 영향을 미치는지에 대한 특수성이 있습니다. 모든 정보가 없으면 간접 참조를 더 많이 추가하고 런타임을 더 많이 추가해야 합니다.

Chris Jenkins: 네. 하지만 JS of OCaml은 Melange에 비해 장점이 많습니다. 엔지니어링에서는 모든 것이 항상 트레이드오프이기 때문에 다른 것보다 엄격하게 더 나은 솔루션을 가질 수는 없습니다. 그런 경우는 매우 드뭅니다. JS of OCaml의 가장 큰 장점은 거의 모든 OCaml 언어를 지원할 수 있다는 것입니다. 앞서 몇 가지 모듈, 몇 가지 표준 라이브러리 모듈, 몇 가지 다른 라이브러리, 몇 가지 구조를 Melange에서 지원할 수 없다고 말씀드렸습니다. 예를 들어 효과 핸들러에 대해 이야기했는데, 이것은 JS of OCaml이 지원하는 기능입니다. JS of OCaml에서 취한 방법은 효과 핸들러를 컴파일하는 경우 모든 함수의 끝에 연속 인수를 추가하는 것입니다. 즉, 프로그램의 모든 함수에 이 마지막 인수가 있어야 하고, JavaScript에서 해당 함수를 호출하려면 어댑터를 제공해야 합니다. 다시 말씀드리지만, 런타임이 발생하고 표현이 그렇게 간단하거나 문서화하기 쉽지 않습니다. 하지만 큰 장점은 훨씬 더 많은 것을 지원한다는 것입니다.

Chris Jenkins: 어떤 의미에서는 상당히 고수준 언어를 다른 고수준 언어로 컴파일하는 것과 비슷하지만, JS of OCaml에서는 기본적으로 바이트코드를 다른 바이트코드로 변환합니다.

Antonio Monteiro: 좋은 비유입니다. 맞습니다.

Chris Jenkins: 트레이드오프를 알겠습니다. 그러면 다른 사람이 Melange를 사용하는 실제적인 측면을 살펴보겠습니다. 저는 JavaScript를 작성하고 싶지 않습니다. TypeScript를 작성하는 것은 괜찮지만, TypeScript에 대한 생각은 JavaScript와 매우 다릅니다. 하지만 PureScript를 작성하는 것은 좋아합니다. ReasonML을 시험해 보고 어떤 느낌인지 알아보고 싶다면 어떻게 시작하는 것이 가장 좋을까요?

Antonio Monteiro: 시작하기 가장 좋은 방법은 mlre.org에 방문하는 것입니다. 시작하기 지침과 모든 문서가 있는 웹사이트입니다. JavaScript를 작성하고 싶지는 않지만 JavaScript 플랫폼에 배포하는 경우 여전히 JavaScript를 많이 사용해야 할 겁니다. 플랫폼 API라도 말입니다. 어느 시점에는 플랫폼 API를 호출해야 합니다. 따라서 mlre.org에는 이러한 모든 작업을 수행하는 방법, 즉 경계에서 코드를 작성하는 방법, 라이브러리를 사용하는 방법, 빌드를 조정하는 방법에 대한 긴 문서 섹션이 있습니다. OCaml Discord 또는 ReasonML Discord에 가입할 수도 있습니다. 항상 Discord에 있고 최대한 도움을 드리려고 노력합니다. 이것이 시작하기 가장 좋은 방법이라고 생각합니다.

Chris Jenkins: 좋습니다. 구체적인 답을 하기는 어렵지만 주관적인 의견을 말씀해 주세요. 이 스택은 얼마나 성숙했나요?

Antonio Monteiro: 어려운 질문입니다. 23년 전에는 조각난 도구 세트만 있었습니다. 이러한 도구를 조합할 수는 있었지만 모든 것을 수동으로 해야 했습니다. 23년 전부터 지금까지 우리 작업의 큰 부분은 이러한 모든 것을 백그라운드에서 처리하여 사용자가 걱정하지 않도록 하는 것이었습니다. 그래서 OCaml 빌드 시스템에 Melange에 대한 지원을 추가하고 OCaml 플랫폼과 원활하게 작동하도록 했으며 그 과정에서 많은 코드를 수정했습니다. 현재는 Melange의 주요 버전을 네 개 출시했고, 요즘에는 많은 사용자가 Melange를 프로덕션 환경에서 사용하고 있습니다. 가장 큰 사용자는 ahrefs입니다. 앞서 말씀드린 것처럼요. 그래서 Melange는 안정적이라고 할 수 있습니다. 프로덕션 환경에 배포해도 도구 선택으로 인해 큰 놀라움이 발생하지 않을 것입니다.

Chris Jenkins: 네. 중요한 인프라에 의존하는 모든 것에 대해 원하는 상태입니다.

Antonio Monteiro: 하지만 에코시스템은 아직 매우 어립니다. Melange를 배포하면 아직 초기 단계에 있다는 것을 알 수 있을 것입니다. 에코시스템이 완전히 갖춰지지 않았고, npm에 있는 JavaScript 라이브러리에 대한 바인딩을 많이 작성해야 하고, 원하는 것을 하기 위해 한두 개의 라이브러리를 직접 작성해야 할 수도 있습니다. 빌드를 구성하는 방법, Dune과 OCaml이 어디에 있는지, 번들러가 어디에서 시작되는지 등을 알아내야 합니다. 이러한 모든 선택은 사용자가 직접 해야 합니다. 우리는 권장 사항이 없습니다. 따라서 많은 것을 알아내야 하고 많은 것을 만져봐야 하지만, 전반적으로 핵심은... 이렇게 말씀드리겠습니다. OCaml에 익숙하다면 Melange 도구에 익숙해질 것입니다. OCaml을 처음 사용하는 경우에는 배울 것이 많습니다.

Chris Jenkins: 네, 당연합니다.

Antonio Monteiro: 네.

Chris Jenkins: 그러면 마지막 질문이 될 수도 있겠습니다. 이제 네이티브 react-ml 날짜 선택기를 작성하는 데 집중하지 않을 것 같습니다. 그 에코시스템을 채우는 일은 하지 않을 것입니다. 이 프로젝트의 미래는 무엇인가요? 앞으로 6개월, 1년 동안 무엇을 작업할 계획인가요?

Antonio Monteiro: 몇 가지 목표가 있습니다. 항상 가장 중요한 것은 개발자 경험입니다. ahrefs 내부에 Melange와 ReasonML을 사용하는 프런트엔드 팀이 있습니다. 그들은 매일 어려움을 겪고 있으며, 그 어려움은 저에게 보고됩니다. 이것은 항상 염두에 두어야 할 사항입니다. 버그를 수정하고 ReasonML 언어 자체의 사용성을 개선할 뿐만 아니라 Melange를 사용할 때 발생하는 버그도 수정해야 합니다. 요즘에는 코드 생성 버그가 거의 없지만, 주로 컴파일러에서 오류 메시지를 표시하고 사용자가 어떻게 해야 할지 모르는 경우 누구의 잘못인지에 대한 문제입니다. 일반적으로 컴파일러의 잘못입니다. 메시지가 도움이 되지 않기 때문입니다. 따라서 우리는 개발자 경험에 많은 노력을 기울이고 있습니다. 또한 프런트엔드와 백엔드에서 코드를 쉽게 공유할 수 있도록 하는 프로젝트를 진행하고 있습니다. Melange로 컴파일된 코드와 네이티브로 컴파일된 코드 사이에서요. 앞서 언급했던 언어별 구문(Closure에서는 reader conditional이라고 부릅니다. 저는 그 표현이 마음에 듭니다)을 어떻게 정의할 수 있을까요? 기본적으로 컴파일할 백엔드를 조건부로 지정하는 컴파일러 지시문입니다. 그 외에도 점점 더 많은 JavaScript 구문을 Melange 측에서 지원해야 합니다. 특히 생각하고 있는 것은 동적 가져오기입니다. JavaScript에서는 가져오기 유형이 두 가지입니다. 하나는 동기식이고 파일의 최상위 수준에 선언으로 배치합니다. "다른 모듈에서 이러한 값을 가져오고 싶습니다."라는 선언입니다. 하지만 동적 또는 비동기 가져오기도 있습니다. 런타임에 다른 모듈이나 다른 번들을 가져올 수 있습니다. 번들러는 일반적으로 이 구조를 사용하여 번들 분할을 정의합니다. "메인 애플리케이션 청크를 제공하고, 런타임에 동적으로 다른 것을 가져오면 메인 번들에 포함될 필요가 없는 다른 논리적 청크에 넣겠습니다."라는 식입니다. 예를 들어 이것은 Melange 로드맵에 있는 기능이고 우리가 작업하고 있으며, OCaml에서 관용적이면서도 JavaScript에서 번들 분할의 이점을 제공하는 솔루션을 제공하려고 노력하고 있습니다.

Chris Jenkins: 이 특정 지점은 Melange의 성숙도 곡선에서 어디에 있는지 잘 보여줍니다. 컴파일러가 실제로 안정되고 사람들이 무언가를 만들고 충분히 큰 프로젝트를 배포하기 시작하면 걱정하기 시작하는 문제이기 때문입니다.

Antonio Monteiro: 맞습니다. 요즘은 그렇게 할 수 있습니다. 우리가 하려는 일은 이를 관용적으로 만드는 방법입니다. Melange에는 효과적으로 JavaScript 코드를 OCaml 파일 내에 작성할 수 있는 탈출 해치가 있습니다. 이 탈출 해치나 FFI 언어(Interop 언어)를 사용하면 동적 가져오기를 작동시킬 수 있으며, Melange를 사용하여 작동시키는 코드베이스를 알고 있습니다. 다만 안전성이 많이 떨어집니다. OCaml 모듈은 타입이 잘 지정되어 있고 시그니처를 정의할 수 있다는 점에 대해 조금 이야기했습니다. 앞으로 나올 내용과 우리가 작업하고 있는 내용을 미리 보여드리자면, 동적으로 가져오는 시그니처를 정의하거나 추론하는 기능입니다. 따라서 OCaml 모듈을 동적으로 가져올 때 모든 것이 여전히 타입 안전하고 OCaml 코드베이스 내에 있는 다른 모듈을 참조하는 것과 같습니다.

Chris Jenkins: 네. 작업의 흥미로운 부분은 번들에 포함되지 않은 무언가에 대해 동적 가져오기를 생성하는 방법, 타입 검사와 시그니처를 보존하는 방법, 안전하지 않은 방식으로 프로그래밍하지 않는 방법입니다.

Antonio Monteiro: 네, 언어의 보장을 잃고 싶지 않고 개발자에게 어려운 일을 만들고 싶지 않습니다.

Chris Jenkins: 맞습니다. 매우 재미있는 작업처럼 들립니다.

Antonio Monteiro: 네, 매우 재미있습니다. 연구도 많이 하고 프로토타입도 많이 만들지만, 몇 가지는 해결책을 찾은 것 같습니다.

Chris Jenkins: 그럼 계속 작업하시도록 하겠습니다. 시간 내주셔서 감사합니다.

Antonio Monteiro: 초대해 주셔서 감사합니다. 정말 즐거웠습니다.

Chris Jenkins: 감사합니다, Antonio. 마무리하기 전에 Antonio의 작업을 지원하고 싶다면 GitHub에서 후원할 수 있습니다. 쇼 노트 아래에 페이지 링크가 있습니다. 회사에서 후원하도록 설득하는 것도 고려해 보세요. 독립 오픈 소스 개발자에게 큰 금액이라도 일반 회사의 IT 예산에는 반올림 오차에 불과하기 때문입니다. 설득할 수 있는 사람이 있다면 그렇게 하세요. 모두에게 좋을 것입니다. 그런 김에 Developer Voices Patreon 계정 링크도 알려드리겠습니다. 이 팟캐스트의 향후 에피소드를 후원하고 쇼가 계속 진행될 수 있도록 도와주세요. 물론 쇼 노트는 이러한 링크와 이 에피소드에서 논의한 프로젝트에 대한 링크를 찾을 수 있는 가장 좋은 곳입니다. 다음 주에는 소프트웨어 개발 세계의 또 다른 뛰어난 인물과 함께 돌아오겠습니다. 구독하시고, 이번 토론이 즐거웠다면 좋아요를 눌러주시고 친구와 공유해 주세요.

Chris Jenkins: 또 할 말이 있나요?

Antonio Monteiro: 네, 향후 게스트에 대한 제안이 있다면 연락처를 통해 알려주세요. 백로그를 처리하고 있지만 항상 더 많은 제안을 환영합니다. 연락 주세요.

Chris Jenkins: 감사합니다. 그럼 저는 호스트 Chris Jenkins였고, 이것은 Antonio Monteiro와 함께한 Developer Voices였습니다. 들어주셔서 감사합니다.

Antonio Monteiro: 감사합니다.