Từ khi Dune trở thành hệ thống build tốt hơn cho OCaml

 (blog.janestreet.com)
1 điểm bởi GN⁺ 2025-02-01 | 1 bình luận | Chia sẻ qua WhatsApp
  • Jane Street từng tạo Jenga vì không hài lòng với OMake, nhưng mức độ được bên ngoài chấp nhận yếu; Jbuilder, vốn được tạo như một lớp tương thích, lại bất ngờ lớn lên thành công cụ nền tảng của cộng đồng OCaml
  • Sức hút ban đầu của Jbuilder không nằm ở tính năng mà ở tốc độ và tính di động; trong các dự án của Jane Street, khả năng biên dịch nhanh hơn OCamlbuild khoảng 5 lần đã thúc đẩy việc áp dụng
  • Jbuilder phát triển thành một hệ thống build hoàn chỉnh nhờ hợp tác với OCaml Labs, và sau thảo luận trong cộng đồng, được đổi tên thành Dune do trùng tên với một Java IDE cũ của Borland
  • Jane Street duy trì song song Jenga và Dune trong một thời gian, nhưng khi codebase tăng lên đến 65 triệu dòng OCaml và 5 triệu dòng Python, độ khó của việc chuyển đổi nội bộ tăng mạnh
  • Sau hơn một năm tập trung thực hiện, codebase của Jane Street hiện được build bằng Dune; các bản build mà phần lớn cache đã được lấp đầy nhanh hơn 2–3 lần

Jenga bắt đầu từ sự không hài lòng với OMake

  • Hệ thống build là công cụ hằng ngày của lập trình viên, dùng để tạo chương trình có thể chạy từ nhiều file nguồn, đồng thời đảm nhiệm cả việc gọi compiler và chạy test
  • Khoảng năm 2012, Jane Street không hài lòng với OMake, một trong các hệ thống build tiêu chuẩn của OCaml, nên tự tạo hệ thống build Jenga
  • Vì Jenga hoạt động tốt trong nội bộ, Jane Street quyết định công khai nó với kỳ vọng cộng đồng cũng có thể dùng hữu ích
    • Họ kỳ vọng người dùng bên ngoài sẽ dùng thử Jenga và đóng góp
    • Họ cũng cho rằng việc công bố mã nguồn mở của Jane Street sẽ trở nên dễ dàng hơn
  • Việc được bên ngoài chấp nhận trên thực tế không đạt kỳ vọng
    • Nó không chạy trên Windows
    • Để dùng Jenga, về cơ bản phải chấp nhận toàn bộ cách build OCaml của Jane Street
  • Khi mức sử dụng bên ngoài không tăng, Jane Street đưa Jenga trở lại dạng không công khai, còn vấn đề build mã nguồn mở vẫn tồn tại

Jbuilder được tạo như một lớp tương thích

  • Năm 2016, Jane Street quyết định tạo Jbuilder, một công cụ đa nền tảng đơn giản để người dùng bên ngoài có thể build code của họ mà không cần chấp nhận toàn bộ Jenga
  • Công cụ này cũng nhằm giảm gánh nặng phải viết lại phần build cho phù hợp với OCamlbuild, vốn khi đó đang nổi lên như tiêu chuẩn mới để build dự án OCaml
  • Jbuilder hiểu các file jbuild mà Jenga dùng cho cấu hình build, và chạy các lệnh biên dịch cần thiết theo thứ tự sắp xếp tô-pô
  • Jbuilder ban đầu khác khá xa một hệ thống build theo nghĩa thông thường
    • Nó không chỉ chọn chạy lại các lệnh có input thay đổi
    • Thay vào đó, mỗi lần nó chạy lại tất cả lệnh

Quá trình Jbuilder trở thành Dune

  • Jbuilder ban đầu được dự định là một lớp tương thích nhỏ, nhưng người dùng bắt đầu dùng nó để build cả dự án của mình, không chỉ các package của Jane Street
  • Yếu tố lớn nhất thúc đẩy việc áp dụng là tốc độ
    • Nhanh hơn OCamlbuild khoảng 5 lần khi biên dịch các dự án của Jane Street
    • Tính di động tốt
    • Cấu trúc đơn giản nên dễ sửa đổi
  • Jane Street bắt đầu hợp tác với OCaml Labs, hiện là Tarides, để phát triển Jbuilder thành một hệ thống build hoàn chỉnh hơn
  • Tên gọi trở thành một vấn đề riêng
    • Đã tồn tại JBuilder, Java IDE của Borland
    • Dù hệ thống đó trên thực tế đã biến mất từ lâu, họ vẫn không được chủ sở hữu bản quyền cho phép dùng tên sau khi hỏi ý định sử dụng
  • Sau thảo luận trong cộng đồng, Dune được chọn làm tên mới

Chi phí duy trì đồng thời hai hệ thống build

  • Khi Dune ngày càng phổ biến, Jane Street phải đồng thời duy trì và hỗ trợ hai hệ thống build hoàn chỉnh do chính họ tạo ra: Jenga và Dune
  • Dune trở thành một hệ thống có kiến trúc được thiết kế lại, hiệu năng nhanh trong hầu hết các bản build của người dùng, mức độ chấp nhận rộng hơn, API và trải nghiệm người dùng tốt hơn
  • Việc khi nào chuyển nội bộ sang Dune tự nhiên trở thành bài toán cần giải, nhưng riêng việc theo kịp codebase đang lớn dần cũng đã khiến đội hệ thống build bận rộn
    • Khi Dune bắt đầu vào năm 2016, mã OCaml có 4 triệu dòng
    • Hiện có 65 triệu dòng OCaml và 5 triệu dòng Python
  • Việc chuyển sang Dune có gánh nặng lớn nên chưa thể bắt tay nghiêm túc, và họ chỉ lặp lại những ước tính lạc quan rằng “có thể làm được trong 6–12 tháng tới”
  • Năm ngoái, Jane Street mở rộng đội hệ thống build lên 5 kỹ sư toàn thời gian, rồi bắt đầu công việc chuyển đổi đã bị trì hoãn lâu dài

Dune thay thế Jenga trong nội bộ Jane Street

  • Một trong những việc lớn nhất là làm cho Dune có thể mở rộng phù hợp với codebase khổng lồ của Jane Street
  • Một lý do Dune nhanh ở bên ngoài là hầu hết người dùng build các dự án nhỏ hơn rất nhiều so với repository 70 triệu dòng của Jane Street
  • Jenga cũng không đứng yên trong suốt 10 năm
    • Jane Street liên tục cải thiện phần triển khai Jenga theo sự tăng trưởng của codebase
    • Jenga đã được tối ưu hóa đáng kể cho các yêu cầu của một monorepo quy mô lớn
    • Phần lớn các tối ưu hóa đó cần được chuyển sang Dune
  • Công việc tích hợp hằng ngày cũng không hề đơn giản
    • Hệ thống build được gọi trong nhiều workflow
    • Ba editor Vim, Emacs và VSCode đều có tích hợp tùy chỉnh riêng cho Jenga
    • Từng phần tích hợp phải được chuyển dần sang Dune
  • Sau hơn một năm tập trung thực hiện, codebase của Jane Street hiện được build bằng Dune
    • Tại thời điểm chuyển đổi, hiệu năng của Dune nhìn chung bằng hoặc tốt hơn Jenga
    • Trong một số trường hợp, hiệu năng tốt hơn rất nhiều
    • Khi phần lớn tác vụ build đã có trong cache, bản build nhanh hơn 2–3 lần

Những cải tiến tiếp theo có thể thực hiện trên một hệ thống duy nhất

  • Jane Street dự định công bố mã nguồn mở phần lớn các cải tiến hiệu năng cho Dune, và một số đã được công bố
  • Để không lại sinh ra hai hệ thống là fork Dune cho Jane Street và Dune bên ngoài, họ chú ý đưa các thay đổi có thể vào upstream
  • Dune trở thành nền tảng phù hợp hơn để tạo tính năng mới
    • Codebase đơn giản hơn và dễ làm việc hơn
    • Có thể tập trung vào một hệ thống duy nhất
  • Các tính năng tiếp theo cũng trở nên gần hơn

    • Build phân tán

      • Build nông, tức “builds without the bytes”
      • Tải cache của chính build graph
      • Đội hệ thống build đã tăng lên 12 kỹ sư toàn thời gian ở New York, London và Singapore, và tốc độ cải thiện Dune cũng tăng lên

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-02-01
Ý kiến trên Hacker News

  • Thông báo crash của Dune:

    Ta sẽ không gây ra segfault. Sự bất định là kẻ giết chết tâm trí. Ngoại lệ là cái chết nhỏ dẫn đến sự hủy diệt hoàn toàn. Ta sẽ biểu đạt trọn vẹn mọi trường hợp. Việc thực thi sẽ đi qua ta và xuyên qua ta. Sau khi nó đi qua, ta sẽ tua ngược stack dọc theo lộ trình của nó. Ở nơi các trường hợp đã được xử lý, sẽ không còn gì cả. Chỉ còn lại ta mà thôi

  • Trên podcast kỹ thuật Signals and Threads của Jane Street có một tập năm 2020 nói về build system, rất đáng nghe
    Các tập khác cũng hay, đặc biệt là The Future of Programming có Richard Eisenberg và What is an Operating System? có Anil Madhavapeddy
    ¥https://signalsandthreads.com/build-systems/
    °https://signalsandthreads.com/future-of-programming/
    §https://signalsandthreads.com/what-is-an-operating-system/

    • Cách ký hiệu chú thích này khá thú vị. Tò mò không biết chỉ là để vui và tăng tính thẩm mỹ, hay có nguồn gốc hoặc mục đích sâu xa hơn
    • Gợi ý hay đấy, và Multicast and the Markets cũng thật sự rất hay
      https://signalsandthreads.com/multicast-and-the-markets/

  • Đáng tôn trọng ở chỗ Jane Street đã chứng minh rằng lập trình hàm với kiểu HM nếu được đầu tư nghiêm túc thì hoàn toàn sẵn sàng cho production và còn có thể rất nhanh
    Đến giờ thỉnh thoảng vẫn nghe người ta nói các ngôn ngữ hàm theo phong cách hàn lâm hơn thì không dùng được trong production, nhưng OCaml cho thấy ngay cả với yêu cầu hiệu năng cao thì vẫn hoàn toàn khả thi

    • Mercury cũng dùng Haskell ở backend
      https://mercury.com/
    • Đúng vậy. F# cũng được dùng khá nhiều trong production
      Đây là một lựa chọn tuyệt vời để tạo ra các chương trình chất lượng cao đồng thời tương tác rộng rãi với các hệ thống hiện có
    • NoRedInk cũng dùng Haskell cho một phần backend, và Elm cho phần lớn frontend
      Theo một bài blog vài năm trước thì họ cũng từng thử Roc, nhưng không rõ bây giờ còn dùng không
      [0] https://blog.noredink.com
    • pandoc cũng được viết bằng Haskell. Facebook trước đây cũng từng dùng Haskell cho chống spam, còn bây giờ thì không rõ
    • Ý là hệ thống kiểu có ảnh hưởng đến tốc độ thực thi sao? Theo mình biết thì hệ thống kiểu chỉ là phân tích tĩnh, nên không ảnh hưởng đến tốc độ runtime

  • Mỗi lần đọc bài trên blog Janestreet, tôi lại tự cười vì cảm giác làm kỹ thuật trong ngành tài chính ở Jane có lẽ còn thú vị hơn và đãi ngộ tốt hơn 90% cái gọi là công việc trong ngành công nghệ

    • Jane Street và một vài công ty tinh hoa chỉ chiếm một tỷ lệ rất nhỏ trong lực lượng kỹ thuật của ngành tài chính
      Có rất nhiều công việc kỹ thuật trong tài chính không hề thú vị hay đãi ngộ tốt bằng cả một công ty công nghệ trung bình, chứ đừng nói đến Jane Street
    • Cỏ bên kia lúc nào cũng xanh hơn
      Phần lớn công việc trong tài chính là sửa code Java 20 năm tuổi hoặc tìm ra cách mới để nhập xuất dữ liệu với file Excel nhằm phục vụ các báo cáo đặt riêng
    • Chỉ là giai thoại không kiểm chứng, nhưng có một đồng nghiệp của tôi làm ở JS được 6 tháng rồi chuyển sang FAANG vì công việc quá chán. Dù lương ở đó còn cao hơn mà vẫn chuyển
      Và tôi nghe nói vào JS còn khó hơn nhiều so với Google/Meta
      Tôi cũng từng ứng tuyển trước đây, nhưng người phỏng vấn khá khó chịu, và tôi chưa từng gặp chuyện đó ở phỏng vấn big tech, nên không để lại ấn tượng tốt
    • Thật vậy sao? Giờ làm dài, tiêu chuẩn thì cực kỳ khắt khe, và suy cho cùng vẫn là thao túng các con số để kiếm lợi nhuận, nên với đa số mọi người đây không phải công việc quá ý nghĩa
      Dù vậy tôi vẫn đánh giá nó cao hơn việc làm cho người ta bấm vào quảng cáo
    • Mọi người đang đánh giá quá cao những gì diễn ra ở Jane Street hay các công ty giao dịch tần suất cao có mức sàng lọc tương tự
      Cũng như các công ty khác thôi, vừa có dự án thú vị vừa có việc chán ngắt

  • Chỉ có build system phức tạp mới tệ hơn một codebase phức tạp. CMake thì thật kinh khủng
    Kiểu như: “Muốn biên dịch ngôn ngữ này thì hãy học thêm một ngôn ngữ mới nữa!”

    • Tệ hơn build system phức tạp là build system đơn giản mà lại không build được thứ bạn cần :(
    • Gần với kiểu “hãy học cái ngôn ngữ mới tệ hại này” hơn
    • Tôi không ghét CMake. Nó khủng khiếp thật, nhưng nếu đã dùng C hay C++ thì tiêu chuẩn vốn đã đặt khá thấp rồi
      Nó vẫn có vài thứ làm đúng, và một số điều làm sai thì vẫn quản lý được
      Nếu chỉ với một bộ file cấu hình có thể chỉnh sửa bằng tay mà có được quy trình build cho nhiều nền tảng thì cũng đáng để chịu đựng phần nào
    • Những ý tưởng trong CMake hiện đại theo hướng target-oriented là có giá trị
      Ngôn ngữ script khủng khiếp của nó đúng là kéo chân mọi thứ lại, nhưng nếu có đủ động lực thì vẫn có thể cải thiện được

  • Trước đây, sau Lisp, trải nghiệm hàm đầu tiên của tôi là dành vài năm với Haskell.
    OCaml không thực sự hợp với tôi, và tôi mắc một dạng dị ứng dấu chấm phẩy khá hiếm, nên Haskell nhìn dễ chịu hơn nhiều.
    Nhưng gần đây tôi thử Reason và thấy rất tuyệt, rồi đột nhiên mọi thứ liên quan đến OCaml trở nên thú vị.

    • F# thiếu một số tính năng thú vị hơn của OCaml, ví dụ như độ biểu đạt của hệ thống module, nhưng có cú pháp nhạy thụt lề nên trong đa số trường hợp loại bỏ được khá nhiều cấu trúc, bao gồm cả dấu chấm phẩy.
      https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
    • “Nếu mục đích là biên dịch hoặc diễn giải tệp như một script, thì trong OCaml có thể và nên tránh dấu chấm phẩy kép. Để lại cũng không gây lỗi, nhưng không có tác dụng gì. Lý do trình biên dịch cho phép điều này là để khi sao chép và dán từ UTop vào tệp, bạn không cần phải xóa chúng.”
      https://ocaml.org/docs/toplevel-introduction#loading-librari...
      https://reasonml.github.io/ trông rất ngầu, giống như OCaml mang phong cách JavaScript.
    • Điều thú vị là điểm tôi luôn ngại ở Haskell là nó tạo cảm giác như chỉ có khoảng trắng và dòng chảy của định danh, không có dấu hiệu trực quan để nhận ra cấu trúc.
      Có lẽ khi nắm được cách nhìn đó thì sẽ ổn, nhưng có vẻ như cũng phải học cách suy nghĩ theo cấu trúc ấy như với Lisp. Dù vậy, nếu cả màn hình đầy mã Haskell thì tôi vẫn thấy ngán.
      Trong số đó, SML/NJ là thứ dễ đọc nhất.
    • Tôi ước cú pháp Reason là cú pháp mặc định.

  • Tôi tò mò không biết có ai đã dùng thư viện và công cụ OCaml mã nguồn mở của Jane Street trong một dự án tương đối nghiêm túc chưa.
    Ấn tượng khi nhìn lướt qua là họ đã bỏ rất nhiều công sức để xây dựng hệ sinh thái và công khai mã nguồn, nhưng có vẻ chưa ở trạng thái thật sự “sẵn sàng” cho người ngoài Jane Street sử dụng.

    • Có, tôi đang dùng. Trong dự án đầu tiên học OCaml, tôi đã dùng bản thay thế thư viện chuẩn của họ, và từ đó tiếp tục dùng luôn.
      Nếu muốn tìm thứ gì đó thì bạn phải đọc chữ ký hàm khá thành thạo, nhưng ngoài ra tôi không có gì để phàn nàn. Ví dụ, việc có sẵn các hàm chuyển đổi qua lại sang s-biểu thức cho mọi kiểu cơ bản tiết kiệm cực nhiều thời gian nếu bạn biết trước để lên kế hoạch.
      Tôi cũng đã dùng các thư viện khác, và ppx cho logging cùng unit test của họ gần như là tiêu chuẩn thực tế trong thế giới OCaml, nếu thứ như vậy có thể tồn tại. Tôi cũng đã dùng formatter, một test framework và cả triển khai cấu trúc dữ liệu nâng cao.
      Thỉnh thoảng đúng là có gặp thứ hoàn toàn không chạy, như các bình luận khác nói. Kiểu phụ thuộc vào một món riêng lẻ nào đó được phát hành mà không có tài liệu, hoặc cần cấu hình bí mật. Không phải do ác ý, và thường nếu mở issue rồi quay lại sau 1–2 năm thì nó đã hoạt động.
      Không phải là không có lúc bực bội, nhưng tôi vẫn trân trọng cách tiếp cận công khai mọi thứ thay vì dồn nguồn lực vào việc kiểm thử và trau chuốt ít bản phát hành hơn. Chất lượng mã nhìn chung rất cao, và ngay cả khi bạn không chạy được trực tiếp thì nó vẫn là một triển khai ví dụ nghiêm ngặt, được kiểm chứng.
    • Không phải dự án nghiêm túc, nhưng tôi dùng stdlib của họ cho trình tạo trang tĩnh cá nhân.
      Theo tôi thì API tốt hơn hẳn stdlib chuẩn.
    • Tôi đã thử dùng công cụ magic-trace, nhưng chỉ với một chương trình dotnet nhỏ thôi mà đã gặp ít nhất 4 kiểu crash khác nhau.
    • Tôi đã dùng ở Bloomberg.
    • Tôi đang chạy test cho một dự án nghiên cứu toán học phức tạp, và thời gian chạy hiện giờ đáng ngạc nhiên là Lean 4 << Haskell << OCaml.
      Tôi thích Lean 4, nhưng không dễ nhận hỗ trợ từ AI. Việc tôi đang làm hôm nay là cố tiêu hóa sách hướng dẫn tham khảo để nó vừa đẹp trong cửa sổ ngữ cảnh 200K. Tôi sẽ xem điều đó có giúp gì không.

  • Tôi khá ngạc nhiên rằng việc phát triển hệ thống build mới nội bộ rồi di chuyển sang đó vẫn có thể hợp lý hơn so với việc áp dụng công cụ sẵn có như buck2 hay bazel.
    Không phải là nói mấy công cụ build cao cấp này dễ triển khai, nhưng nếu so với tự làm thì sao? Tôi tò mò liệu dune có điểm gì đặc biệt khiến nó khác biệt nhiều đến vậy không.

    • Về chi tiết cụ thể thì chắc những người nhiều kinh nghiệm sẽ nói tốt hơn, nhưng khi JS bắt đầu tự làm công cụ riêng vào năm 2012 thì buck và bzl đều chưa tồn tại.
      Bản phát hành đầu tiên của Bazel là năm 2015, còn Buck là 2013.
      JS đúng là có phần văn hóa NIH, nhưng tôi không biết ở đây điều đó có đóng vai trò không. Khi đó không có nhiều công cụ build tốt, đặc biệt là cho các công ty dùng stack kỹ thuật không chính thống.
    • Tôi không rành OCaml đến mức đó, nhưng theo hiểu biết của tôi thì trong số những cái được nhắc đến, hệ thống build thực sự có ngữ nghĩa để biên dịch OCaml đúng cách chỉ có buck2.
      Đặc biệt, dường như cần có khả năng chạy ocamldep trước hoặc biên dịch hai lần; buck2 làm được, còn Bazel theo tôi nhớ thì cần hack.
    • Nhóm của chúng tôi có một codebase OCaml lớn và hai hệ thống build song song, tức buck2 và dune.
      Hai bên nhìn chung khá tương đồng. Về tốc độ thuần khi gọi các công cụ build OCaml thì dune nhanh hơn; còn khi phải build lại nhiều thứ và có dùng hệ thống build phân tán thì buck2 thắng.
      Nỗi đau lớn là tích hợp LSP. Vì cách duy nhất để máy chủ LSP biết được phụ thuộc của tệp là thông qua build, nên nó phải gắn rất chặt với hệ thống build. Với dune thì mọi thứ được cung cấp rất gọn gàng. Với buck2 thì chúng tôi cũng ghép nối được, nhưng không tốt bằng.

  • Dune đúng là cái tên hay nhất có thể có cho một hệ thống build, không có đối thủ nào đến gần.

    • Chuẩn. “Ai kiểm soát hệ thống build thì kiểm soát vũ trụ.”
    • Vì phần mềm được xây trên cát chuyển động chăng?

  • Thật kỳ lạ khi họ bắt đầu với ý định tạo ra một hệ thống build tốt hơn rồi lại “tình cờ” tạo ra một hệ thống build tốt hơn; cái kiểu ngẫu nhiên đó đúng là lạ thật.