Mojo 1.0 Beta

 (mojolang.org)
3 điểm bởi GN⁺ 7 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Mojo là một ngôn ngữ theo đuổi khẩu hiệu “viết như Python, chạy như C++”, hiện cung cấp bản ổn định 1.0.0b1 (May 7)
  • Mục tiêu là cho phép viết mã nhanh trên nhiều loại phần cứng, từ CPU đến GPU, mà không bị phụ thuộc vào một nhà cung cấp cụ thể, và được thiết kế như một ngôn ngữ kiểu tĩnh hiệu năng cao cho hệ thống AI hiện đại
  • Hỗ trợ khả năng tương tác với Python ở mức native, nên có thể chỉ chuyển các điểm nghẽn hiệu năng sang Mojo mà không cần viết lại toàn bộ mã hiện có; hỗ trợ cả việc import mã Mojo từ Python và import thư viện Python trong mã Mojo
  • Có thể viết GPU kernel bằng cùng một ngôn ngữ, đồng thời hướng tới cung cấp tối ưu hóa theo từng phần cứng và trừu tượng hóa không tốn chi phí thông qua metaprogramming ở thời điểm biên dịch dùng cùng ngôn ngữ với mã runtime
  • Thư viện chuẩn của Mojo đã được công bố mã nguồn mở hoàn toàn trên GitHub và đang nhận đóng góp; trình biên dịch Mojo có kế hoạch mã nguồn mở vào năm 2026

Phiên bản và tài liệu bắt đầu

  • Bản ổn định hiện tại là 1.0.0b1 (May 7), bản nightly mới nhất là May 9
  • Mojo lấy cảm hứng từ cú pháp trực quan của Python, tính an toàn bộ nhớ của Rust và metaprogramming mạnh mẽ, trực quan ở thời điểm biên dịch của Zig
  • Là một ngôn ngữ kiểu tĩnh được biên dịch, cũng phù hợp cho lập trình theo kiểu agent
  • Thay vì buộc phải chọn giữa năng suất và hiệu năng, Mojo hướng tới cung cấp cả hai; có thể bắt đầu bằng các mẫu lập trình đơn giản, quen thuộc và chỉ thêm độ phức tạp khi cần
  • Các lối vào để bắt đầu gồm Install Now, Quickstart, Releases, Roadmap, GitHub
  • Để xem trang ở dạng Markdown, có thể thêm .md vào URL; toàn bộ chỉ mục tài liệu Mojo có thể xem tại llms.txt

GPU và khả năng tương tác với Python

  • Lập trình GPU

    • Mojo hướng tới việc giúp tiếp cận lập trình GPU mà không cần thư viện riêng theo từng nhà cung cấp hay mã biên dịch tách biệt
    • Có thể viết GPU kernel hiệu năng cao bằng chính ngôn ngữ đang dùng cho CPU
    • Kernel ví dụ vector_add nhận TileTensor và thực hiện result[i] = a[i] + b[i] dựa trên global_idx.x 
      def vector_add(  
    a: TileTensor[float_dtype, type_of(layout), element_size=1, ...],  
    b: TileTensor[float_dtype, type_of(layout), element_size=1, ...],  
    result: TileTensor[  
        mut=True, float_dtype, type_of(layout), element_size=1, ...  
    ],  
):  
    var i = global_idx.x  
    if i < layout.size():  
        result[i] = a[i] + b[i]

  • Khả năng tương tác với Python

    • Mojo có khả năng tương tác native với Python, nên có thể loại bỏ các điểm nghẽn hiệu năng mà không cần viết lại toàn bộ mã hiện có
    • Có thể bắt đầu từ một hàm, rồi mở rộng dần theo cách chuyển các phần mã quan trọng về hiệu năng sang Mojo khi cần
    • Mã Mojo có thể được import tự nhiên vào Python và được đóng gói cùng các package để triển khai
    • Ngược lại, trong mã Mojo cũng có thể import các thư viện trong hệ sinh thái Python
    • Hàm ví dụ mojo_square_array lấy con trỏ từ ctypes.data của PythonObject, tính độ rộng SIMD tại thời điểm biên dịch và bình phương các phần tử trong mảng 
      # SIMD-vectorized kernel squaring array elements in place.  
def mojo_square_array(array_obj: PythonObject) raises:  
    comptime simd_width = simd_width_of[DType.int64]()  
    ptr = array_obj.ctypes.data.unsafe_get_as_pointer[DType.int64]()  
    def pow[width: Int](i: Int) unified {mut ptr}:  
        elem = ptr.load[width=width](i)  
        ptr.store[width=width](i, elem * elem)  
    vectorize[simd_width](len(array_obj), pow)

Metaprogramming ở thời điểm biên dịch

  • Metaprogramming của Mojo cung cấp một hệ thống trực quan giúp tối đa hóa hiệu năng bằng cách dùng cùng một ngôn ngữ với mã runtime
  • Có thể tạo tối ưu hóa riêng cho từng phần cứng bằng biên dịch có điều kiện, bảo đảm an toàn bộ nhớ bằng đánh giá ở thời điểm biên dịch và loại bỏ các nhánh runtime tốn kém
  • Mục tiêu là cung cấp trừu tượng hóa không tốn chi phí trong khi vẫn thể hiện rõ ý đồ
  • Ví dụ triển khai __eq__ sử dụng phản chiếu ở thời điểm biên dịch để lấy tên và kiểu của các trường trong struct, kiểm tra mọi trường có thỏa mãn Equatable hay không rồi thực hiện so sánh equality theo từng trường 
    # Generic struct equality using compile-time reflection.  
@always_inline  
def __eq__(self, other: Self) -> Bool:  
    comptime r = reflect[Self]()  
    comptime names = r.field_names()  
    comptime types = r.field_types()  
    comptime for i in range(names.size):  
        comptime T = types[i]  
        comptime assert conforms_to(T, Equatable), "All fields must be Equatable"  
        if trait_downcast[Equatable](  
            r.field_ref[i](self)  
        ) != trait_downcast[Equatable](r.field_ref[i](other)):  
            return False  
    return True

Lộ trình và mã nguồn mở

  • Mojo bắt đầu vào cuối năm 2022 và vẫn còn nhiều việc cần làm

  • Phase 0

    • Giai đoạn xây dựng nền tảng ban đầu
    • Đây là giai đoạn triển khai parser cốt lõi, kiểu bộ nhớ, hàm, struct, initializer, quy ước đối số và các nền tảng ngôn ngữ khác

  • Phase 1

    • Giai đoạn hiện đang diễn ra
    • Mục tiêu là biến Mojo thành một ngôn ngữ mạnh mẽ, giàu khả năng biểu đạt để viết kernel hiệu năng cao trên CPU, GPU và ASIC, đồng thời giúp lập trình viên mở rộng Python một cách liền mạch

  • Phase 2

    • Giai đoạn lập trình ứng dụng hệ thống
    • Đây là giai đoạn mở rộng để hỗ trợ mô hình an toàn bộ nhớ được đảm bảo và nhiều khả năng trừu tượng hơn mà các lập trình viên hệ thống mong đợi

  • Phase 3

    • Giai đoạn lập trình hướng đối tượng động
    • Đây là giai đoạn hỗ trợ thêm nhiều tính năng động của Python như class, kế thừa, biến không kiểu nhằm tối đa hóa khả năng tương thích với mã Python
    • Có thể xem chi tiết tại Mojo roadmap
    • Thư viện chuẩn của Mojo đã được công bố mã nguồn mở hoàn toàn trên GitHub và đang nhận đóng góp
    • Trình biên dịch Mojo có kế hoạch được mã nguồn mở vào năm 2026
    • Dù có chủ trương mã nguồn mở toàn bộ Mojo, nhưng do ngôn ngữ vẫn còn rất non trẻ, nhóm cho rằng một nhóm kỹ sư gắn kết, có chung tầm nhìn có thể tiến nhanh hơn mô hình do cộng đồng dẫn dắt
    • Kênh tham gia được cung cấp qua developer community

Tài liệu học tập và cộng đồng

  • Install và Quickstart guide: tài liệu bắt đầu với Mojo
  • Beginner tutorial: học Mojo bằng cách tạo Game of Life
  • GPU puzzles: học lập trình GPU với Mojo qua việc giải đố
  • Intro to Mojo: giới thiệu tổng quan các tính năng ngôn ngữ của Mojo
  • Developer forum: nơi đặt câu hỏi và cập nhật về Mojo
  • Events: thông tin về sự kiện, meetup, bài trình bày và hackathon
  • Contributions: hướng dẫn về issue mở, đóng góp tài liệu và chia sẻ dự án

Bài viết liên quan

1 bình luận

 
GN⁺ 7 giờ trước
Ý kiến trên Hacker News

  • Trong 2 năm qua tôi đã dùng Mojo khá nhiều cho vui, và đây thực sự là một ngôn ngữ rất tuyệt
    Nó có mô hình ownership gần với Rust, thực thi ở thời điểm biên dịch mạnh hơn Zig, hệ thống kiểu phong phú, và hỗ trợ SIMD hạng nhất
    Về mặt hiệu năng, lâu lắm rồi mới thấy một ngôn ngữ trông không chỉ như một lớp bọc LLVM đơn thuần. Nó vẫn dùng LLVM, nhưng tận dụng theo cách khác với Rust hay Zig
    Khi được mã nguồn mở vào cuối năm nay, Mojo sẽ rất đáng mong đợi

    • Sẽ tốt hơn nếu giải thích thêm về phần “thực thi ở thời điểm biên dịch mạnh hơn Zig”
      Chỉ nhìn tài liệu Mojo hiện tại thì khó đi đến kết luận đó

  • Với tư cách là người làm machine learning và quan tâm đến hiệu năng, tôi hy vọng Mojo sẽ thành công. Đặc biệt, tôi háo hức với khả năng trộn code GPU và code CPU trong cùng một ngôn ngữ
    Tuy vậy, tôi lo những thay đổi hiện tại có thể khiến các nhà phát triển Python xa rời nó. Lần gần nhất tôi chạy thử, tôi muốn test thao tác chuỗi cơ bản bằng var x = 'hello'; print(x[3]) nhưng không chạy, và len(x) cũng không được nên tôi đã loay hoay cả tiếng đồng hồ
    Hóa ra họ quyết định tách rõ hơn giữa biểu diễn byte và code point, nhưng tài liệu lại mâu thuẫn với phần triển khai thực tế
    Tôi hy vọng nó sẽ đạt đến mức đủ dùng cho machine learning nói chung, nhưng hiện tại vẫn còn khá hạn chế. Một số tính năng cơ bản ổn cho tensor cũng đã bị bỏ đi
    Trước mắt tôi sẽ tiếp tục dùng JAX và thỉnh thoảng kiểm tra lại

    • Tôi không hiểu vì sao đến giờ vẫn chưa có ngôn ngữ nào có thể biến code thiên về tính toán đơn giản thành SIMD / đa luồng / đa tiến trình / code GPU chỉ với lượng cú pháp bổ sung tối thiểu
      Đây chẳng phải kiểu giấc mơ mà những người quan tâm đến compiler và thiết kế ngôn ngữ nên theo đuổi sao
      Không cần phải đảm bảo hiệu quả trong mọi tình huống hay đạt hiệu năng tối tân, chỉ cần nó tồn tại là cũng tốt rồi
      Tôi hiểu là có thể làm ra ngôn ngữ như vậy, nhưng có vẻ chưa đủ hấp dẫn với những người có khả năng làm nó
    • Mojo thì hay đấy, nhưng tôi không hiểu vì sao họ cứ bám vào tính tương thích ngược với Python. Vì thế mà họ đang tự trói chân mình
      Gần như mọi nhược điểm tôi nghĩ tới ở Kotlin đều xuất phát từ tính tương thích với Java. Ở đây có lẽ vẫn có thể giải quyết tốt hơn bằng cách tường minh hơn, nhưng hướng hiện tại có vẻ như thất bại là điều khó tránh
    • Nếu không mã nguồn mở thì hầu như vô nghĩa. Đa số nhà phát triển Python dù sao cũng sẽ không đến
    • Ở khía cạnh này, trông nó gần như là đang cố tạo lại ngôn ngữ lập trình Nim

  • Có ghi rằng “họ đã hứa sẽ mã nguồn mở Mojo vào mùa thu năm 2026”
    https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced

    • Sẽ rất hay nếu có thể xem mã nguồn của một chương trình MLIR thực sự tiên tiến

  • Đáng tiếc là trong thời gian đó Nvidia cũng không đứng yên, và đã tạo ra thế hệ CUDA tiếp theo là CuTile cho Python, sắp tới là cho C++, thông qua một stack compiler tương tự dựa trên MLIR
    Dù không có tính di động, chỉ riêng việc Nvidia hậu thuẫn mạnh, tích hợp vào công cụ phát triển, và chạy cùng code CUDA hiện có cũng khiến nó có khả năng được dùng nhiều hơn Mojo rất nhiều
    Có lẽ Tile IR gần với phản ứng trước mối đe dọa từ Triton hơn là từ Mojo. Tôi đặc biệt nghĩ vậy nếu xét theo góc độ viết kernel LLM có hiệu năng khá tốt dễ đến mức nào

    • Để không bị tụt lại, Intel và AMD cũng đang có những nỗ lực tương tự, và CPython JIT cuối cùng cũng đang trở thành hiện thực sau nhiều lần thử
      Cũng có những nỗ lực như GraalPy và PyPy
      Tất cả các nỗ lực này đều đang chạy trên Windows, điều này khá quan trọng trong môi trường công ty nơi phần lớn nhân viên được cấp máy Windows còn chỉ server mới dùng các bản phân phối Linux
      Điều đó cứ khiến tôi nghĩ liệu đây có lại là một cái kết kiểu Swift for Tensorflow nữa không
    • Theo những gì tôi nghe được khi nói chuyện với một vài nhà phát triển Tile IR, động lực chính là cung cấp tính di động tốt hơn cho việc lập trình tensor core so với PTX
      Ngoài phản hồi từ khách hàng, tôi không nghe ai nói đây là phản ứng trước điều gì khác
    • Nhiều người nhầm tưởng Mojo chỉ là cú pháp tiện để viết code GPU, và rằng framework Python của Nvidia đã làm được việc đó rồi
      Nhưng liệu CuTile có chạy được trên GPU AMD hay Apple Silicon không? Nvidia làm gì đi nữa thì sự phụ thuộc vào nhà cung cấp vẫn còn nguyên
    • Tôi tò mò không biết tầm ảnh hưởng của CuTile lớn đến đâu

  • Khi mới nghe về Mojo, tôi nghĩ nó được làm để tương thích với code Python hiện có
    Nhưng trong tương lai gần, mục tiêu đó có vẻ rất xa vời. Bạn có thể gọi qua lại giữa Python và Mojo, nhưng bản thân Mojo không thể chạy code Python hiện có

    • Trong phần quảng bá ban đầu, rõ ràng đây là một trong những điểm cốt lõi. Kiểu như chỉ cần thêm type hint vào code Python là có thể đạt tăng tốc rất lớn
      Nhưng có vẻ trong quá trình phát triển, hướng đi đã thay đổi
    • Nếu tôi nhớ không nhầm thì họ còn quảng cáo nhanh hơn Python tương đương tới 36.000 lần, nhưng hoàn toàn không làm rõ rằng điều đó chỉ khả thi ở các trường hợp biên cực đoan
      Nó giống một kế hoạch crypto kiểu pump-and-dump hơn là một nỗ lực chân thành nhằm cải thiện hệ sinh thái Python
    • Nếu nhìn thật kỹ thì ngay từ đầu đã khá rõ rằng ý tưởng là tạo ra ngôn ngữ hệ thống thế hệ tiếp theo
      Nó lấy bài học từ Swift và Rust, nhắm đến các mục tiêu CPU/GPU/dị thể, và lấy MLIR làm trung tâm
      Đồng thời, cấu trúc cũng được định hình để sau này có thể nhúng hoặc mở rộng Python tương đối dễ, và cách đóng khung theo Python gần như chắc chắn đã giúp ích cho việc gọi vốn
      Chris Lattner đã nói về mối quan hệ giữa MLIR và Mojo nhiều hơn là giữa Python và Mojo
    • Quảng cáo ban đầu đúng là như vậy. Họ muốn trở thành một thứ giống Kotlin đối với Python nhưng nhanh chóng đổi hướng
      Điều đó cộng với mô hình phát triển chưa hoàn toàn mã nguồn mở khiến nó lúc nào cũng mang cảm giác như vaporware
    • Trên website có viết thế này
      Tính tương tác với Python: “Mojo tương tác gốc với Python, nên bạn có thể loại bỏ các nút thắt hiệu năng trong code hiện có mà không cần viết lại mọi thứ. Bạn có thể bắt đầu từ một hàm và mở rộng dần bằng cách chuyển phần code quan trọng về hiệu năng sang Mojo khi cần. Code Mojo có thể được import tự nhiên vào Python và đóng gói cùng nhau để triển khai. Tương tự, thư viện trong hệ sinh thái Python cũng có thể được import vào code Mojo”

  • Mojo có vẻ ổn, nhưng với tính toán số hiệu năng cao trên cả CPU lẫn GPU thì hiện tại tôi khá hài lòng với Julia
    Ngoài việc dùng cú pháp giống Python, có cảm giác ngách này phần lớn đã được giải quyết. Ngay cả Python cũng có những công cụ như Numba và Triton, hiệu quả cho các loại bài toán ít phức tạp hơn và độc lập hơn

  • Nếu cùng mục tiêu thì Julia đã trưởng thành hơn, và từ năm ngoái Nvidia cũng đang đưa công cụ Python và công cụ C++ trên CUDA về mức ngang nhau về tính năng
    Với trình biên dịch JIT cuTile cho Python, bạn có thể viết kernel CUDA gần như bằng Python thuần
    AMD và Intel cũng đang theo đuổi cách tiếp cận tương tự
    Còn việc Mojo có đến kịp để giành được mức chấp nhận rộng hơn hay không thì vẫn phải chờ xem

    • Nói rằng trình biên dịch JIT cuTile cho Python cho phép viết kernel CUDA bằng Python thuần là không đúng. Hiện tại không phải Python thuần và sau này cũng sẽ không thể như vậy
      Những phương ngữ Python “thân thiện với hiệu năng” này, tức Triton, Pythran, CuTile, Numba, Pycell, cuPy v.v., bề ngoài trông như Python nhưng chỉ cần cào nhẹ lớp vỏ là thấy hoàn toàn không phải Python
      Chúng là các DSL kiểu Python được thiết kế để tối ưu hóa và suy luận kiểu hoạt động tốt
      Khi dùng thực tế sẽ cảm nhận rất rõ điều đó. Trong từng cái, nhiều, có lẽ là phần lớn tính năng Python, không thể dùng được, nhưng vẫn phải gánh các vấn đề cố hữu của Python
      Thành thật mà nói, Python vốn dĩ không phù hợp với hiệu quả và hiệu năng
      Đây là vấn đề vượt xa GIL. Kiểu động, ngữ nghĩa tham chiếu, monkey patching, mô hình đối tượng cực kỳ động, CPython ABI, BigInt mặc định, hệ thống module thời gian chạy... đều hợp lý cho một ngôn ngữ scripting nhỏ, nhưng rất tệ cho tính toán hiệu năng cao và hiệu suất
      Bản thân hệ sinh thái NumPy/SciPy cũng gần như là một tập hợp các cách lách để né tránh giới hạn của Python cho bài toán số tensor CPU-bound đơn giản
      Hiệu năng Python gốc quá tệ đến mức chỉ một vòng lặp for đơn giản cũng đủ khiến Excel trông như ngựa đua
      Mojo thì khác
      Thay vì chắp vá trên một nền tảng cũ đầy vấn đề, Mojo cố gắng bắt đầu từ một điểm xuất phát sạch sẽ
      Và thay vì dựa trên Python hơn 30 năm tuổi, nó muốn mang lại “trải nghiệm giống Python” bằng một ngôn ngữ được thiết kế bài bản trên nền kinh nghiệm thiết kế ngôn ngữ hiện đại
      Chỉ riêng vì lý do đó thôi tôi cũng hy vọng nó thành công

  • Dạo này có vẻ ít nhất với một bộ phận người dùng, quảng cáo nhấn mạnh AI native là điều cần thiết
    Nhưng với tôi thì nó hơi gây phản cảm. Vì trông như một cụm từ thực ra chẳng nói lên điều gì
    Liệu những người hào hứng với AI có thể giải thích vì sao câu “vì là ngôn ngữ được biên dịch và có kiểu tĩnh nên cũng lý tưởng cho lập trình tác tử” lại như vậy, và thực sự nó có nghĩa gì không

    • Kể từ khi AI được đẩy lên nổi bật, thật thú vị khi thấy sự tuyệt vọng trên trang đầu của các sản phẩm và dịch vụ kiểu này
      Cá nhân tôi thấy buồn cười nhất là lúc mở trang sản phẩm IBM DB2 lên và thấy dòng AI database
      Có lẽ ý là nếu bắt được nhiều lỗi hơn ở thời điểm biên dịch, tác tử có thể nhanh chóng tự kiểm tra công việc của mình theo cách tĩnh mà không cần unit test hay các bài test khác
    • Các LLM hiện nay được huấn luyện trên một thư viện khổng lồ các đoạn code trong quá khứ. Vì vậy trong tương lai gần, chúng sẽ hoạt động tốt hơn với những ngôn ngữ đã có chỗ đứng so với ngôn ngữ mới
      Đặc biệt các ngôn ngữ như Python có rất nhiều mã nguồn mở sẵn dùng sẽ có lợi thế. Đây là vấn đề lớn với người mới khi không có code hiện có để học theo
      Vì thế để trông có vẻ liên quan trong thế giới “tác tử”, có thể họ cần kiểu marketing AI native đầy tuyệt vọng này. Có đủ hay không thì thời gian sẽ trả lời
    • Tôi không nghĩ mình là người cuồng AI, nhưng tôi có dùng thật
      Tác tử có xu hướng làm tốt hơn khi nhận được nhiều phản hồi hơn. Kiểm tra kiểu rất hữu ích để tự động bắt khá nhiều lỗi ngớ ngẩn
      Ý chính là, tác tử có càng nhiều gợi ý thì nhìn chung càng tốt
    • Tôi không rõ người ta dùng câu đó với ý gì, và tôi đồng ý rằng cụm “AI native” trong các ngôn ngữ lập trình như thế này khá vô nghĩa
      Còn về biên dịch và kiểu tĩnh, khi lập trình theo kiểu tác tử thì việc phát hiện vấn đề ở thời điểm biên dịch rất có ích
      Nhờ đó sẽ ít gặp vấn đề hơn ở runtime, và cũng giảm các tình huống mà tác tử khó giải quyết. Unit test có thể lấp một phần khoảng trống, nhưng không hoàn toàn
      Điều website không nói là Mojo thậm chí có thể là lựa chọn tệ cho lập trình tác tử. Vì hiện tại chưa có nhiều dữ liệu huấn luyện cho Mojo
    • Đây là kiểu khẩu hiệu mới của “...on the blockchain”
      Python+ruff+pycheck và TypeScript được biên dịch thành bytecode chứ không phải mã máy. Chúng cũng không phải kiểu tĩnh theo nghĩa của Rust
      Thế mà tôi vẫn thấy mô hình tạo ra code hợp lệ khá tốt cho cả hai. Không nhất thiết phải “biên dịch” nghiêm ngặt hay “kiểu tĩnh”
      Cuối cùng, AI không quá quan tâm đến các thuộc tính đó miễn là có công cụ tốt để kiểm tra code nhanh và lặp lại

  • Modular dự kiến sẽ mã nguồn mở toàn bộ Mojo SDK, bao gồm cả compiler, vào cuối năm nay
    Có ghi rằng “Mojo 1.0 sẽ được chốt vào cuối năm nay, cùng với việc công bố compiler và đảm bảo tính ổn định của ngôn ngữ”
    https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-...

  • Tôi vẫn đang theo dõi Mojo. Thành thật mà nói, thứ tôi không thích nhất ở Python là cú pháp
    Có người ở đây nhắc đến Julia, và tôi nghĩ đó là một ngôn ngữ tốt. Nhưng thông báo lỗi từ compiler và tài liệu thư viện vẫn chưa đạt mức tôi kỳ vọng ở một ngôn ngữ trưởng thành đến vậy
    Tôi cũng lo về vấn đề độ chính xác trong các bài blog từng đọc. Ngoài ra, vì kích thước binary và thời gian chạy lần đầu, tôi không nghĩ có thể làm module Python theo kiểu mình muốn bằng Julia
    Dù vậy, tôi vẫn hy vọng Mojo trở thành một lựa chọn. Nhưng tôi thích REPL và cũng thích tính động của Python, nên có thể cuối cùng tôi vẫn sẽ không rời khỏi NumPy chỉ vì hiệu năng

    • Với tôi thì ngược lại. Thứ duy nhất tôi thích ở Python là cú pháp
      Vì vậy tôi thực sự rất thích Nim. Có được tốc độ cấp C, thực thi thời điểm biên dịch, metaprogramming, hệ thống kiểu mạnh, an toàn bộ nhớ, mà code vẫn thường ngắn gọn và thanh lịch
      Mojo cũng thú vị, nhưng đến nay có vẻ tập trung chủ yếu vào machine learning hơn là lập trình mục đích chung. Và theo tôi biết compiler vẫn chưa mã nguồn mở
    • Tôi rất thích thiết kế của Mojo. Nó quản lý bộ nhớ theo cách xác định, nên không thể so sánh với Julia
      Có vẻ Mojo cũng tập trung hơn vào việc trở thành một ngôn ngữ đủ vững cho môi trường công nghiệp. Tôi từng bị sốc khi thấy bản triển khai precompile đầu tiên của Julia không cung cấp I/O file