Pyrefly - trình kiểm tra kiểu mới và trải nghiệm IDE cho Python

• Pyrefly của Meta là một trình kiểm tra kiểu cho Python mã nguồn mở đồng thời là tiện ích mở rộng cho IDE, được phát triển bằng Rust
• Hỗ trợ hiệu năng phân tích cực nhanh và tích hợp IDE, được phát triển để vượt qua các giới hạn của Pyre
• Lấy suy luận kiểu tự động, hỗ trợ codebase lớn và triết lý mã nguồn mở làm các nguyên tắc cốt lõi
• Mục tiêu là cải thiện hệ thống kiểu trên toàn hệ sinh thái thông qua hợp tác và đóng góp cùng cộng đồng Python
• Hiện đã phát hành bản alpha và đang tích cực kêu gọi phản hồi cũng như đóng góp từ cộng đồng

---

Giới thiệu

• Pyrefly là dự án mã nguồn mở gồm trình kiểm tra kiểu tĩnh cho Python và tiện ích mở rộng IDE do Meta phát triển bằng Rust
• Hỗ trợ phát hiện lỗi sớm bằng cách xác minh tính nhất quán của kiểu trước khi chạy mã
• Có thể dùng cả với IDE lẫn CLI, mang lại quy trình làm việc linh hoạt
• Hướng tới đóng góp cho hệ thống kiểu của Python và sự phát triển của nhiều thư viện khác nhau thông qua hợp tác với cộng đồng mã nguồn mở

Bối cảnh phát triển Pyrefly

• Năm 2017, Meta đã phát triển một trình kiểm tra kiểu mới cho codebase Python quy mô lớn của Instagram; về sau đó là Pyre
• Pyre tham khảo thiết kế vững chắc từ Hack, Flow..., và được viết bằng OCaml để tối ưu hiệu năng
• Theo thời gian, khi hệ thống kiểu phát triển và nhu cầu tích hợp IDE tăng lên, các giới hạn bắt đầu xuất hiện
• Meta cũng sử dụng các công cụ cộng đồng như Pyright, nhưng do vẫn có hạn chế trong việc đáp ứng các yêu cầu như duyệt code quy mô lớn và xuất kiểu, nên đã bắt tay phát triển Pyrefly

Các nguyên tắc chính của Pyrefly

• 1. Hiệu năng

  • Nhà phát triển cần kiểm tra kiểu nhanh ở mỗi lần gõ phím ngay sau khi viết mã
  • Pyrefly có kiến trúc triển khai Rust hiệu năng cao, có thể kiểm tra 1,8 triệu dòng mỗi giây ngay cả với codebase cực lớn

• 2. Thiết kế lấy IDE làm trung tâm

  • Hệ thống trừu tượng được thiết kế ngay từ đầu để IDE và CLI giữ cùng một góc nhìn
  • Nếu như với Pyre đây là phần được bổ sung về sau, thì với Pyrefly tính nhất quán đã được nhấn mạnh ngay từ giai đoạn thiết kế

• 3. Inference (suy luận)

  • Hỗ trợ tự động suy luận kiểu ngay cả với mã Python không có chú thích và không khai báo kiểu rõ ràng
  • Hiển thị kiểu của giá trị trả về và biến cục bộ trong IDE, đồng thời cho phép tự động chèn kiểu được suy luận khi nhấp đúp để hỗ trợ viết mã tốt hơn

• 4. Mã nguồn mở

  • Pyrefly được công khai trên GitHub theo giấy phép MIT, hoan nghênh PR và báo cáo issue từ cộng đồng
  • Hướng tới giao tiếp sôi nổi qua kênh Discord, đồng thời liên kết với hệ sinh thái Python và các thư viện chủ chốt của Meta như PyTorch

Tương lai của Pyrefly

• Đang hoạt động với mục tiêu cải thiện ngôn ngữ Python và trải nghiệm nhà phát triển cùng cộng đồng
• Ngay từ giai đoạn đầu phát triển Pyre, Meta đã duy trì việc mở mã nguồn và đóng góp cho PEP; với Pyrefly, công ty cũng có kế hoạch tối đa hóa lợi ích của việc sử dụng kiểu cho nhiều nhà phát triển, thư viện và cả người mới bắt đầu
• Dựa trên kinh nghiệm và thành quả trong việc áp dụng kiểu cho ngôn ngữ động, Meta dự định chia sẻ nhiều trải nghiệm hơn và thúc đẩy nâng cao chất lượng kiểu trong hệ sinh thái
• Hiện Pyrefly vẫn là bản alpha, nhưng đang liên tục sửa lỗi và bổ sung tính năng với mục tiêu ra mắt chính thức vào mùa hè này
• Phản hồi từ cộng đồng là rất quan trọng, và Meta tích cực kêu gọi báo cáo issue cũng như đề xuất cải tiến sau khi sử dụng Pyrefly

Hướng dẫn về bản alpha của Pyrefly và cộng đồng

• Quá trình phát triển Pyrefly và các chi tiết kỹ thuật đã được chia sẻ qua Meta Tech Podcast, các bài trình bày tại PyCon US và nhiều kênh khác
• Thông tin bổ sung sẽ được cung cấp qua nhiều kênh như các trang liên quan đến Meta Open Source, YouTube, Facebook, Threads, X và LinkedIn

[GN⁺]

Ý kiến trên Hacker News

• Thay mặt cho "Python Language Tooling Team" của Meta, tôi có chút lo lắng; uv quá phổ biến nên có linh cảm ty sẽ thắng trong lĩnh vực này. Nếu không cẩn thận, có thể rơi vào tình huống như Atom hay Flow, khi đội nội bộ bị dự án mã nguồn mở bên ngoài lấn át và từ cấp trên sẽ xuất hiện bầu không khí kiểu "đội này có thật sự cần thiết không? Hay chuyển sang dùng mã nguồn mở đi". Tôi nghĩ đây là điều phía quản lý (Aaron Pollack?) cần lưu tâm.
  • Kevin, chào mọi người, trước đây từng làm ở Flow và hiện đang làm trong đội Pyrefly. Lần này chúng tôi chọn cách tiếp cận khác với Flow và đã xác định rất rõ việc mã nguồn mở cùng xây dựng cộng đồng là ưu tiên hàng đầu. Gần đây có nhiều biến động liên quan đến đầu tư hạ tầng của các công ty, nhưng ở thời điểm hiện tại tôi tin rằng chúng tôi đang ở đúng điểm khởi đầu của một hành trình đúng đắn. Xin gửi lời cảm ơn vì sự ủng hộ.
  • Có ý kiến cho rằng Meta đặc biệt coi trọng quyền kiểm soát đối với các dự án mã nguồn mở về công cụ phát triển. Trước đây từng có chuyện bên duy trì git chỉ ra vấn đề với việc dùng monorepo và từ chối đưa hướng cải thiện lên upstream, nên Meta đã chuyển sang mercurial; phía mercurial thì sẵn sàng nhận đóng góp. Vì các công cụ nội bộ thay đổi quá nhanh nên việc tự sở hữu dự án riêng là hợp lý.
  • Trong số những thứ xuất phát từ Facebook, tôi thích JSX nhất (có lẽ là thứ duy nhất tôi thấy ổn).
• Tôi đang làm trong đội Pyrefly của Meta. FAQ đã trả lời khá nhiều câu hỏi, nên mời mọi người tham khảo link ở đó. Nếu còn câu hỏi khác tôi cũng sẵn lòng trả lời, và cảm ơn mọi người đã quan tâm.
• Dạo này đã xuất hiện ba trình kiểm tra kiểu Python viết bằng Rust (Microsoft, Facebook, Astral), trong khi mypy hiện có vẫn tiếp tục tồn tại.
  • Chỉnh lại là trình kiểm tra kiểu của Microsoft, Pyright, được viết bằng Typescript. Dù vậy, theo trải nghiệm cá nhân thì nó vẫn nhanh hơn mypy.
  • Có phải tất cả đều là trình kiểm tra kiểu tĩnh không? Không có cái nào dành cho runtime à?
• Đây là lần công bố chính thức, nhưng Pyrefly thực ra đã được bàn luận từ vài tuần trước. Hiện tại nó đang được phát hành ở giai đoạn alpha, tập trung vào sửa lỗi và phát triển tính năng, với mục tiêu gỡ nhãn alpha vào mùa hè, theo phát biểu chính thức của đội.
• Phần mã Rust được viết ở đây rất dễ hiểu, nhưng tôi lo ngại về việc các công cụ Python gần đây cứ tiếp tục được viết bằng Rust, và lại sinh ra một biến thể nữa của vấn đề có quá nhiều ngôn ngữ. Hy vọng Mojo có thể làm được gì đó ở đây.
  • Trong hệ sinh thái Python, việc dùng Python cho những gì Python xử lý tốt, còn dùng Rust hay C cho nơi cần hiệu năng cao là một xu hướng tự nhiên. Cuối cùng thì N=3 (Python, Rust, C), chỉ là về lâu dài tôi mong C sẽ dần biến mất khỏi lập trình ứng dụng. Nhưng thực tế chắc sẽ mất rất nhiều thời gian; thậm chí có thể chính Python mới trở thành legacy.
• Thật vui vì có hướng dẫn cách tích hợp với Vim/Neovim, kèm link liên quan.
• Tôi không hiểu vì sao việc viết bằng Rust lại được nhắc như một ưu điểm lớn. Hầu hết mọi người đâu có chạy trình kiểm tra kiểu trên hệ thống nhúng hay dịch vụ mission-critical; cảm giác cũng giống như nói "được viết bằng Erlang". Những phần không phải mã cần hiệu năng cao thì viết bằng Python sẽ mở ra nhiều cơ hội hơn cho cộng đồng tham gia và mở rộng, nên tôi không hiểu vì sao lại ám ảnh với Rust đến vậy.
  • Chia sẻ từ kinh nghiệm dùng Rust: với người dùng thì có lợi thế về tốc độ và độ an toàn, còn từ góc nhìn nhà phát triển thì dễ đóng góp hơn. Tôi nghĩ sức hút của Astral cũng nằm ở việc mang các công cụ dựa trên Rust như thế này đến với Python. Dù tôi biết Python nhiều hơn Rust, tôi vẫn thấy đóng góp cho một dự án Rust dễ hơn. Theo tôi, việc chuyển các công cụ chất lượng kiểu Rust sang Python mới là mục tiêu tổng thể.
  • Tôi cho rằng LSP (Language Server Protocol) là loại mã mà hiệu năng cực kỳ quan trọng. Nó ảnh hưởng trực tiếp đến độ phản hồi của IDE. Rust rất hiệu quả cả về CPU lẫn bộ nhớ. Nếu nó được viết bằng OCaml, Reason, Haskell... thì có lẽ tốc độ và hiệu quả vẫn đủ tốt, nhưng tập người đóng góp sẽ rất hạn chế.
  • Chỉ cần tìm kiếm kiểu "[mô tả công cụ] rust" là có thể dễ dàng tìm được phần mềm hiệu năng tốt, điều này khiến tôi hài lòng. Khoảng 95% công cụ tôi dùng được viết bằng Rust, và phần lớn tôi đều rất hài lòng.
  • Rust được dùng như một dạng viết tắt cho ý "nhanh đến mức có thể nhận ra", và điều quan trọng là mã nguồn mở viết bằng Rust vẫn có thể được review.
  • Trình kiểm tra kiểu viết bằng Python thiếu hiệu năng. Ví dụ, các linter viết bằng Python như Pylint phải kiểm tra từng dòng mã, có thể mất hơn 30 giây, nên đây rõ ràng là lĩnh vực mà hiệu năng rất quan trọng.
• Tôi tò mò về việc chuyển từ Pyre sang Pyrefly và việc viết lại hoàn toàn bằng Rust. Tôi muốn biết những lợi ích hay động cơ cụ thể đằng sau việc chuyển từ một ngôn ngữ ít phổ biến hơn sang Rust đang thịnh hành.
  • Câu hỏi này đã được trả lời trong FAQ của chúng tôi. Khi có thêm kinh nghiệm, chúng tôi cũng muốn viết một bài blog dài để chia sẻ kỹ hơn. Có kèm link.
• Có cảm giác đây là một dự án đang cố giải quyết quá nhiều thứ cùng một lúc.
• Tôi mất hứng ngay khi thấy VS Code. Tôi không hiểu vì sao mọi người lại nghĩ VS Code phù hợp làm IDE cho Python, khi đã có những IDE "thực thụ" như PyCharm thì chẳng có lý do gì để dùng VS Code.
  • Pyrefly không bị bó buộc vào riêng vscode. Mong bạn cân nhắc hơn đến chuyện mỗi người có một sở thích khác nhau. PyCharm cũng không hẳn lúc nào cũng tốt hơn. Cá nhân tôi thấy remote development trên vscode rất tiện, nhưng tôi cũng chẳng muốn lên mạng đăng rằng pycharm dở tệ.