1 điểm bởi GN⁺ 2025-06-15 | 1 bình luận | Chia sẻ qua WhatsApp
  • OxCaml là một bộ tiện ích mở rộng bổ sung các tính năng hướng hiệu năng cho OCaml
  • Đây là trình biên dịch production của Jane Street đồng thời đóng vai trò phòng thí nghiệm cho các tính năng tương lai của OCaml
  • Dự án hướng tới mở rộng khả năng kiểm soát hiệu năng, với trọng tâm là tính an toàn, sự tiện dụng và khả năng dự đoán
  • Cung cấp nhiều tính năng ở các lĩnh vực như fearless concurrency, kiểm soát layout, kiểm soát cấp phát
  • Được cung cấp dưới dạng mã nguồn mở, cho phép người dùng thử nghiệm và nhà nghiên cứu tự do kiểm thử và đóng góp ý kiến

Giới thiệu OxCaml

OxCaml là gì

  • OxCamlmột tập hợp các tiện ích mở rộng đang phát triển nhanh dành cho ngôn ngữ lập trình OCaml
  • Đây là trình biên dịch dùng trong thực tế của Jane Street, đồng thời là nền tảng thử nghiệm nhằm tăng cường lập trình lấy hiệu năng làm trung tâm cho OCaml
  • Mục tiêu là đóng góp các tiện ích mở rộng này vào OCaml chính thức về lâu dài

Các mục tiêu thiết kế chính của OxCaml

  • Mục tiêu là cung cấp một môi trường có thể kiểm soát các yếu tố quyết định hiệu năng của hành vi chương trình một cách an toàn, tiện lợi và có thể dự đoán
  • Việc kiểm soát này chỉ được cung cấp theo lựa chọn khi thực sự cần thiết
  • Mọi thứ đều được triển khai trong môi trường OCaml

Phương án thiết kế cụ thể

  • Tính an toàn: tăng cường tính an toàn ở cấp độ ngôn ngữ để đảm bảo năng suất của lập trình viên và tính đúng đắn của mã. Các ngôn ngữ không an toàn trên diện rộng rất khó sử dụng

  • Sự tiện dụng: cung cấp khả năng kiểm soát mà không làm tăng độ phức tạp của việc lập trình, đồng thời vẫn giữ được lợi ích của suy luận kiểu

  • Khả năng dự đoán: biểu lộ một cách tường minh ở cấp hệ thống kiểu các đặc tính hiệu năng cốt lõi, giúp dễ suy luận về hiệu năng của mã

  • Các tiện ích mở rộng này áp dụng theo kiểu pay-as-you-go, chỉ dùng ở nơi cần thiết. Nghĩa là nếu không sử dụng tính năng mở rộng, bạn vẫn có thể giữ nguyên sự đơn giản và các mẫu quen thuộc của OCaml hiện có

  • OxCaml tương thích với mọi chương trình OCaml và về mặt nội bộ hướng tới một OCaml đã tiến hóa. Nó vẫn giữ nguyên tính an toàn, dễ sử dụng và năng suất vốn có của OCaml

Giới thiệu các tính năng mở rộng của OxCaml

Fearless concurrency

  • Để giải quyết việc lập trình đồng thời đúng cách là rất khó, OxCaml dùng phần mở rộng của hệ thống kiểu để ngăn chặn data race một cách tĩnh

Layouts

  • Cho phép lập trình viên chỉ định tường minh layout dữ liệu trong bộ nhớ
  • Đồng thời cung cấp truy cập native tới các phần mở rộng bộ xử lý SIMD trên phần cứng hiện đại

Kiểm soát cấp phát

  • Cung cấp các công cụ kiểm soát chi tiết việc cấp phát bộ nhớ, giúp giảm gánh nặng của garbage collection (GC), đồng thời cải thiện hiệu quả cache và tính quyết định của chương trình

Cải thiện chất lượng sử dụng (Quality of life)

  • Ngoài lập trình hệ thống, còn cung cấp các tính năng hữu ích trong công việc hằng ngày

    • Polymorphic parameters
    • Include functor
    • Labeled tuples
    • Immutable arrays

Cách sử dụng và áp dụng OxCaml

  • OxCaml là mã nguồn mở, vì vậy nhà nghiên cứu, người dùng thử nghiệm và lập trình viên đều có thể đóng góp thông qua kiểm thử và phản hồi

  • Tuy nhiên, các tính năng mở rộng của OxCaml không cam kết ổn định hay tương thích ngược (nhưng vẫn đảm bảo tương thích ngược với các chương trình OCaml hiện có)

  • Cung cấp các phiên bản đã được điều chỉnh cho OxCaml của những công cụ OCaml tiêu chuẩn

    • Quản lý gói: tương thích với dune và opam
    • Tích hợp trình soạn thảo: hỗ trợ LSP-server
    • Tích hợp định dạng mã nguồn và tạo tài liệu
  • Nhiều thư viện và công cụ do Jane Street công bố được cung cấp theo hai dạng

    • Dành cho upstream OCaml: phiên bản đã loại bỏ các phần mở rộng OxCaml
    • Dành riêng cho OxCaml: phiên bản tận dụng các tính năng mở rộng
  • Một số tính năng mở rộng không thể loại bỏ, vì vậy các thư viện đó chỉ có thể dùng trên OxCaml. Khi các phần mở rộng cần thiết được tích hợp vào OCaml chính thức, phiên bản tương thích với OCaml cũng sẽ được công bố

1 bình luận

 
GN⁺ 2025-06-15
Ý kiến trên Hacker News
  • Tôi muốn giới thiệu rằng trong một tập podcast có sự tham gia của những người đứng sau dự án này từ nhóm Janet Street, đã có một cuộc thảo luận thú vị về các cân nhắc hiệu năng khi làm việc với OCaml
    Những trăn trở về việc áp dụng ngôn ngữ GC vào môi trường độ trễ cực thấp vẫn luôn tiếp diễn
    Ví dụ, nếu GC pause xảy ra giữa lúc đang giao dịch tần suất cao thì đó có thể là một vấn đề cực kỳ nghiêm trọng
    Chia sẻ liên kết podcast

    • Chia sẻ trải nghiệm từng trực tiếp hỏi Ron Minsky trên Twitter vì sao không dùng Rust cho ứng dụng độ trễ thấp
      Trong câu trả lời của Ron, ông vừa công nhận Rust rất xuất sắc, vừa tập trung vào giá trị của việc giữ toàn bộ code trong một ngôn ngữ duy nhất
      Khả năng chia sẻ type, tool, thư viện, thành ngữ và sự dễ dàng khi di chuyển giữa các dự án là rất lớn
      Ngoài ra, OCaml cũng đang phát triển theo hướng tích hợp tốt các ưu điểm chính của Rust để có thể tận dụng dần dần
      Các nhược điểm của Rust được nhắc tới gồm thời gian biên dịch dài, hệ thống kiểu phức tạp và sự khó chịu với xử lý async/await
      Trên hết, ông nhấn mạnh lập trường muốn có một công cụ ngôn ngữ duy nhất phù hợp với phạm vi công việc rộng
      Liên kết tweet tương ứng

    • Nhấn mạnh rằng bản thân ngôn ngữ GC không phải vấn đề cốt lõi, mà vấn đề nằm ở góc nhìn coi mọi ngôn ngữ GC như nhau
      Vấn đề thực sự quan trọng là khi ngôn ngữ GC không hỗ trợ thao tác tường minh với stack và value type
      Nếu muốn vừa có năng suất của ngôn ngữ GC vừa có các tùy chọn tinh vi cho lập trình cấp hệ thống, có thể cân nhắc các lựa chọn như Cedar, họ Oberon, Modula-3, D, Nim, Eiffel, C#, F#, Swift, Go

    • Một nhận xét chung về môi trường runtime dùng GC là có thể tận dụng các thuật toán thu gom song song của JVM để giảm thiểu GC pause
      Tuy nhiên, cách này không mang lại bảo đảm đồng đều nên có thể cần overprovision thêm RAM hệ thống
      Xa hơn nữa, cũng có cách cố ý overprovision server để một số server tạm thời rời khỏi pool và xử lý "offline GC"
      Cách làm này đòi hỏi router điều phối request và sự phối hợp giữa các server, nên chỉ có ý nghĩa khi có đủ ngân sách để mở rộng hạ tầng
      Giải thích về Parallel GC của JVM

    • Chia sẻ rằng nhiều hệ thống đã khổ sở vì vấn đề GC compaction
      Trong các hệ thống giao dịch, thông thường người ta áp dụng chính sách giảm thiểu allocation sau khi khởi động
      Trong JS có một thư viện tên là "Zero" cung cấp các tiện ích theo hướng không allocation

    • Dù chưa kiểm tra liên kết, có ý kiến rằng trong những môi trường như giao dịch, nơi có thời điểm mở và đóng phiên, có thể tắt GC trong thời gian giao dịch rồi khởi động lại sau khi kết thúc phiên

  • Tôi muốn nhấn mạnh rằng tính năng đầu tiên từ nhánh fork này được upstream là labeled tuple
    Dự kiến sẽ được hỗ trợ trong OCaml 5.4
    Liên kết PR upstream
    Liên kết thảo luận liên quan

    • Dù tính năng này có vẻ hơi nhỏ, cá nhân tôi vẫn khá hào hứng
      Tôi cũng muốn bổ sung thông tin về bài báo và video mà tác giả của tính năng này đã trình bày tại ML2024
      Video Youtube
      PDF bài báo

    • Ví dụ về labeled tuple có thể giúp tránh nhầm lẫn thứ tự trong một cặp, nhưng cá nhân tôi thích anonymous record của F# hơn
      Ví dụ như {| product = 6; sum = 5 |}, vì thứ tự các field không mang ý nghĩa nên không xảy ra nhầm lẫn

    • Immutable array từ nhánh fork này cũng đã được nhập vào 5.4, chỉ khác đôi chút về cú pháp

    • Nhấn mạnh rằng anonymous labeled struct và enum là những tính năng tôi mong muốn hàng đầu ở một ngôn ngữ lập trình
      Ví dụ, trong Rust có thể định nghĩa cả struct có nhãn và không nhãn
      Nhưng thật tiếc là không thể dùng anonymous labeled struct cho kiểu trả về của hàm

      struct Foo(i32, i32);
      struct Bar{sum: i32, product: i32}
      fn can() -> (i32, i32)
      fn cant() -> {sum: i32, product: i32}
      
  • Tôi không biết nhánh fork này còn hỗ trợ cả SIMD
    Nếu có unboxed type, tính năng cấp phát tường minh trên stack, và cả hỗ trợ Windows, thì cá nhân tôi nghĩ OxCaml hoàn toàn có thể trở nên đáng dùng thay cho F# trong các bối cảnh tiêu dùng như game dev

    • Hiện tại 128-bit SSE/NEON đã hoạt động và AVX cũng sẽ sớm được hỗ trợ
      Hỗ trợ Windows không phải bị chặn hoàn toàn, nhưng vẫn cần thêm một chút công sức
      Cá nhân tôi muốn nhấn mạnh rằng OxCaml đã bổ sung hỗ trợ SIMD
  • Chia sẻ mẹo thiết lập biến môi trường cho những ai đang dùng opam switch mới
    env OCAMLPARAM="alert=-unsafe_multidomain,_," opam install cohttp-lwt-unix
    Nếu alert bị nâng cấp thành lỗi, việc cài các package cũ có thể bị hỏng một cách không cần thiết
    Có thể ngăn vấn đề cài đặt này bằng cách tắt alert tương ứng qua biến môi trường OCAMLPARAM

  • Vì đã quen với plugin vscode rất tốt cho Golang, tôi thắc mắc liệu hệ sinh thái OCaml có kế hoạch tích hợp với vscode hay không
    Tích hợp với vscode đã giúp việc thiết lập trở nên rất đơn giản

    • Bản thân plugin vscode cho OCaml đã hỗ trợ khá nhiều cho việc tích hợp các cú pháp mới như dune, menhir, reason
      Nếu OxCaml trở nên phổ biến hơn thì việc tích hợp tiến triển thêm là điều rất tự nhiên
      Cá nhân tôi dùng emacs nên khó nói chi tiết, nhưng đây có vẻ là hướng phát triển hợp lý
  • Tôi muốn nhắc tới một phiên bản kích thước siêu nhỏ của OcaML
    Liên kết dự án mlite

  • Có người hỏi liệu mục đích công khai dự án này có phải để LLM lập chỉ mục thông tin rồi tận dụng cho mô hình mở hay không

    • LLM ngay cả với OCaml thông thường còn quá yếu và lượng dữ liệu cũng ít, nên với OxCaml vốn còn ít tài liệu hơn thì khả năng đó gần như không có
      Với mục đích như vậy thì tự làm một MCP tài liệu riêng còn có ý nghĩa hơn

    • Giá trị như một tín hiệu là không đủ, nên thực tế gần như vô nghĩa
      Ví dụ, ngay cả với Gleam hoàn chỉnh thì hiệu năng của LLM vẫn rất thấp; dù đưa ra pattern rõ ràng và hướng dẫn lỗi sai thì nó vẫn thất bại
      Vì vậy, nếu nói mục đích là để cung cấp thông tin cho OxCaml thì tín hiệu này quá yếu

  • Một điểm thú vị để theo dõi là OxCaml là phần mở rộng của một phương ngữ thuộc họ ML lại tiếp tục được mở rộng thành một phương ngữ khác
    Tôi khá mong chờ xem bước tiếp theo sẽ trông như thế nào

    • Tôi từng tự hỏi giữa những người cứ tiếp tục gắn thêm tính năng vào ngôn ngữ sẵn có và những người ngay từ đầu tạo ra ngôn ngữ mới thì bên nào rắc rối hơn
      Bản thân tôi thuộc nhóm sau, nhưng tôi nghĩ lập trình viên có một đặc tính mang tính di truyền là không thể để yên công cụ như hiện trạng của nó

    • Một lời gợi ý đùa nửa thật rằng biết đâu cũng nên thử giới thiệu cả F#

  • Có ý kiến xác nhận rằng việc dự án này dùng tên "oxidized" là do liên quan đến các mục tiêu tính năng kiểu Rust (ví dụ: fearless concurrency, tránh GC, v.v.), chứ không phải vì nó thực sự dùng Rust
    Đây là một cách đặt tên có phần dễ gây nhầm lẫn

    • Thật ra còn có một chi tiết mỉa mai nhỏ là tên Rust không đến từ hiện tượng gỉ sét mà từ nấm mốc "Rust"

    • Chia sẻ rằng Jane Street từ lâu đã có một loạt bài blog mang tên 'Oxidizing OCaml'

    • Thuật ngữ này cũng từng xuất hiện trong tiêu đề bài báo "Oxidizing OCaml with Modal Memory Management", nhưng trong bài không có chỗ nào định nghĩa rõ hoặc trích dẫn cụ thể từ "oxidize"
      Dù khá kỳ lạ, đây vẫn là một cái tên rất dễ gây nghiện

    • Dự đoán rằng về phía Rust, việc tích hợp với tracing GC tùy biến — thứ vẫn có thể xử lý các cấu trúc đồ thị điển hình mà vẫn tối đa hiệu năng — sẽ thực tế hơn cho đến khi dự án này đạt được mức tương đương tính năng với Rust
      Nếu không thì nó chỉ tạo cảm giác đang được duy trì chủ yếu vì đã có nhiều codebase liên quan đến OxCaml mà thôi