Mojo 1.0 เบต้า

 (mojolang.org)
3 คะแนน โดย GN⁺ 7 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Mojo เป็นภาษาที่ชูแนวคิดว่า “เขียนเหมือน Python, ทำงานเหมือน C++” และขณะนี้มีรุ่นเสถียรเป็น 1.0.0b1 (May 7)
  • มีเป้าหมายให้เขียนโค้ดที่รวดเร็วได้บนฮาร์ดแวร์หลากหลายตั้งแต่ CPU ไปจนถึง GPU โดยไม่ผูกติดกับผู้ขายรายใดรายหนึ่ง และถูกออกแบบให้เป็นภาษาสแตติกไทป์ประสิทธิภาพสูงสำหรับ ระบบ AI สมัยใหม่
  • รองรับ การทำงานร่วมกับ Python แบบเนทีฟ จึงสามารถย้ายเฉพาะคอขวดด้านประสิทธิภาพมาเป็น Mojo ได้โดยไม่ต้องเขียนโค้ดเดิมใหม่ทั้งหมด และรองรับทั้งการ import โค้ด Mojo จาก Python และการ import ไลบรารี Python ในโค้ด Mojo
  • สามารถเขียน GPU kernel ได้ด้วยภาษาเดียวกัน และมุ่งให้ compile-time metaprogramming ที่ใช้ภาษาเดียวกับโค้ดรันไทม์มอบการปรับแต่งตามฮาร์ดแวร์และ abstraction ที่ไม่มีต้นทุน
  • ไลบรารีมาตรฐานของ Mojo เปิดเป็น โอเพนซอร์สเต็มรูปแบบบน GitHub และเปิดรับการมีส่วนร่วม ส่วนคอมไพเลอร์ของ Mojo มีแผน โอเพนซอร์สในปี 2026

เวอร์ชันและข้อมูลเริ่มต้น

  • รุ่นเสถียรปัจจุบันคือ 1.0.0b1 (May 7) และ nightly ล่าสุดคือ May 9
  • Mojo ได้แรงบันดาลใจจากไวยากรณ์ที่เข้าใจง่ายของ Python, ความปลอดภัยด้านหน่วยความจำของ Rust และ compile-time metaprogramming ที่ทรงพลังและตรงไปตรงมาของ Zig
  • ในฐานะภาษาสแตติกไทป์ที่คอมไพล์ได้ จึงเหมาะกับการเขียนโปรแกรมแบบเอเจนต์เช่นกัน
  • เป้าหมายคือมอบทั้งประสิทธิภาพการพัฒนาและสมรรถนะ แทนที่จะต้องเลือกอย่างใดอย่างหนึ่ง โดยเริ่มจากแพตเทิร์นการเขียนโปรแกรมที่เรียบง่ายและคุ้นเคย แล้วเพิ่มความซับซ้อนเมื่อจำเป็นได้
  • เส้นทางเริ่มต้นที่มีให้คือ Install Now, Quickstart, Releases, Roadmap, GitHub
  • หากต้องการดูหน้าในรูปแบบ Markdown สามารถเติม .md ต่อท้าย URL ได้ และดูดัชนีเอกสาร Mojo ทั้งหมดได้ที่ llms.txt

GPU และการทำงานร่วมกับ Python

  • การเขียนโปรแกรม GPU

    • Mojo มีเป้าหมายให้เข้าถึงการเขียนโปรแกรม GPU ได้โดยไม่ต้องใช้ไลบรารีเฉพาะผู้ขายหรือโค้ดคอมไพล์แยกต่างหาก
    • สามารถเขียน GPU kernel ประสิทธิภาพสูงได้ด้วยภาษาเดียวกับที่ใช้บน CPU
    • ตัวอย่างเคอร์เนล vector_add รับ TileTensor แล้วทำ result[i] = a[i] + b[i] โดยอิงจาก 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]

  • การทำงานร่วมกับ Python

    • Mojo ทำงานร่วมกับ Python ได้แบบเนทีฟ และสามารถแก้คอขวดด้านประสิทธิภาพได้โดยไม่ต้องเขียนโค้ดเดิมใหม่ทั้งหมด
    • สามารถเริ่มจากฟังก์ชันเดียว แล้วค่อยขยายโดยย้ายโค้ดที่ต้องการประสิทธิภาพสูงมาเป็น Mojo ตามความจำเป็น
    • โค้ด Mojo สามารถถูก import ใน Python ได้อย่างเป็นธรรมชาติ และรวมเป็นแพ็กเกจสำหรับการแจกจ่ายได้ด้วย
    • ในทางกลับกัน ภายในโค้ด Mojo ก็สามารถ import ไลบรารีจาก ecosystem ของ Python ได้เช่นกัน
    • ฟังก์ชันตัวอย่าง mojo_square_array จะดึงพอยน์เตอร์จาก ctypes.data ของ PythonObject แล้วคำนวณความกว้าง SIMD ตอนคอมไพล์เพื่อยกกำลังสองสมาชิกในอาร์เรย์ 
      # 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)

compile-time metaprogramming

  • metaprogramming ของ Mojo ใช้ภาษาเดียวกับโค้ดรันไทม์ เพื่อมอบระบบที่เข้าใจง่ายและดึงประสิทธิภาพสูงสุดออกมา
  • สามารถสร้างการปรับแต่งตามฮาร์ดแวร์ด้วย conditional compilation, รับประกันความปลอดภัยของหน่วยความจำด้วยการประเมินผลตอนคอมไพล์ และตัด branching ตอนรันไทม์ที่มีต้นทุนสูงออกได้
  • เป้าหมายคือมอบ abstraction ที่ไม่มีต้นทุน พร้อมสื่อเจตนาได้อย่างชัดเจน
  • ตัวอย่างการทำ __eq__ ใช้ compile-time reflection เพื่อดึงชื่อและชนิดของฟิลด์ใน struct จากนั้นตรวจสอบว่าทุกฟิลด์เป็นไปตาม Equatable แล้วจึงเปรียบเทียบความเท่ากันทีละฟิลด์ 
    # 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

โรดแมปและโอเพนซอร์ส

  • Mojo เริ่มต้นขึ้นในช่วงปลายปี 2022 และยังมีงานที่ต้องทำอีกมาก

  • Phase 0

    • ระยะวางรากฐานเริ่มต้น
    • เป็นช่วงที่พัฒนา parser หลัก, memory type, ฟังก์ชัน, struct, initializer, calling convention และพื้นฐานภาษาอื่น ๆ

  • Phase 1

    • ระยะที่กำลังดำเนินอยู่ในปัจจุบัน
    • เป้าหมายคือทำให้เป็นภาษาที่ทรงพลังและแสดงออกได้ดีสำหรับการเขียนเคอร์เนลสมรรถนะสูงบน CPU, GPU และ ASIC พร้อมเปิดทางให้นักพัฒนาขยาย Python ได้อย่างลื่นไหล

  • Phase 2

    • ระยะการเขียนโปรแกรมแอปพลิเคชันระดับระบบ
    • เป็นช่วงขยายให้รองรับโมเดลความปลอดภัยของหน่วยความจำที่รับประกันได้ และความสามารถด้าน abstraction เพิ่มเติมตามที่นักพัฒนาสาย system programming คาดหวัง

  • Phase 3

    • ระยะการเขียนโปรแกรมเชิงวัตถุแบบไดนามิก
    • เป็นช่วงเพิ่มการรองรับความสามารถแบบไดนามิกของ Python ให้มากขึ้น เช่น class, inheritance และตัวแปรไร้ชนิด เพื่อให้เข้ากันได้กับโค้ด Python สูงสุด
    • รายละเอียดเพิ่มเติมดูได้ที่ Mojo roadmap
    • ไลบรารีมาตรฐานของ Mojo เปิดเป็น โอเพนซอร์สเต็มรูปแบบบน GitHub และเปิดรับการมีส่วนร่วม
    • คอมไพเลอร์ของ Mojo มีแผนจะโอเพนซอร์สในปี 2026
    • แม้จะมีแนวทางที่จะโอเพนซอร์ส Mojo ทั้งหมด แต่เนื่องจากภาษายังใหม่มาก จึงมองว่ากลุ่มวิศวกรที่ทำงานใกล้ชิดกันและมีวิสัยทัศน์ร่วมกันสามารถเดินหน้าได้เร็วกว่าแนวทางที่ขับเคลื่อนโดยชุมชนในช่วงนี้
    • ช่องทางการมีส่วนร่วมคือ developer community

แหล่งเรียนรู้และชุมชน

  • Install และ Quickstart guide: แหล่งข้อมูลเริ่มต้นสำหรับ Mojo
  • Beginner tutorial: เรียนรู้ Mojo ผ่านการสร้าง Game of Life
  • GPU puzzles: เรียนรู้การเขียนโปรแกรม GPU ด้วย Mojo ผ่านการแก้ปริศนา
  • Intro to Mojo: แนะนำความสามารถของภาษา Mojo โดยรวม
  • Developer forum: คำถามและอัปเดตเกี่ยวกับ Mojo
  • Events: ข้อมูลกิจกรรม มีตอัป งานบรรยาย และแฮกกาธอน
  • Contributions: ข้อมูลเกี่ยวกับ issue ที่เปิดอยู่ การช่วยเขียนเอกสาร และการแชร์โปรเจกต์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 7 시간 전
ความเห็นจาก Hacker News

  • ตลอด 2 ปีที่ผ่านมา ผมลองใช้ Mojo เล่นๆ อยู่เยอะมาก และมันเป็นภาษาที่เจ๋งจริงๆ
    มีโมเดล ownership ที่ใกล้กับ Rust, การรันตอน compile time ที่ทรงพลังกว่า Zig, ระบบ type ที่หลากหลาย, และรองรับ SIMD แบบ first-class
    ในแง่ประสิทธิภาพก็ดูเหมือนภาษาแบบจริงจัง ไม่ใช่แค่ตัวห่อ LLVM ธรรมดาๆ ที่เจอมานานแล้ว LLVM ยังถูกใช้อยู่ แต่ใช้งานในแบบที่ต่างจาก Rust หรือ Zig
    ถ้า Mojo กลายเป็นโอเพนซอร์สช่วงปลายปีนี้ ก็น่าคาดหวังมาก

    • อยากให้ช่วยอธิบายเพิ่มหน่อยตรงที่บอกว่า “การรันตอน compile time ที่ทรงพลังกว่า Zig”
      เพราะดูจากเอกสารของ Mojo ตอนนี้อย่างเดียว ยังยากที่จะสรุปแบบนั้นได้

  • ในฐานะคนทำแมชชีนเลิร์นนิงที่สนใจเรื่องประสิทธิภาพ ก็หวังว่า Mojo จะประสบความสำเร็จ โดยเฉพาะจุดที่สามารถผสมโค้ด GPU กับโค้ด CPU ได้ในภาษาเดียว
    แต่ก็กลัวว่าการเปลี่ยนแปลงตอนนี้จะทำให้นักพัฒนา Python ถอยห่างไป ตอนที่ลองรันครั้งล่าสุด ผมแค่จะทดสอบการจัดการสตริงพื้นฐานด้วย var x = 'hello'; print(x[3]) แต่มันไม่ทำงาน และ len(x) ก็ใช้ไม่ได้ เลยนั่งงมอยู่เป็นชั่วโมง
    สุดท้ายพบว่าเขาตัดสินใจแยกการแทนค่าแบบไบต์กับ codepoint ให้ชัดเจนขึ้น แต่เอกสารกลับขัดกับตัว implementation จริง
    หวังว่าจะไปถึงจุดที่ใช้กับแมชชีนเลิร์นนิงทั่วไปได้ด้วย แต่ตอนนี้ยังรู้สึกว่าถูกจำกัดอยู่มาก ฟีเจอร์พื้นฐานดีๆ ที่เกี่ยวกับ Tensor บางอย่างก็ถูกถอดออกไปแล้ว
    ช่วงนี้คงใช้ JAX ต่อไปแล้วค่อยกลับมาดูเป็นระยะ

    • ไม่เข้าใจว่าทำไมถึงยังไม่มีภาษาที่แปลงโค้ดเชิงคำนวณง่ายๆ ให้เป็น SIMD / multithread / multiprocessing / โค้ด GPU ได้ โดยเพิ่มไวยากรณ์ให้น้อยที่สุด
      มันดูเหมือนเป็นสิ่งที่คนสนใจ compiler กับการออกแบบภาษาน่าจะใฝ่ฝันถึงไม่ใช่หรือ
      ไม่จำเป็นต้องรับประกันประสิทธิภาพในทุกสถานการณ์หรือให้ประสิทธิภาพระดับล้ำที่สุดก็ได้ แค่มีอยู่ก็ยังดี
      ผมเข้าใจว่าภาษาแบบนี้น่าจะสร้างได้ แต่เหมือนจะยังดึงดูดความสนใจจากคนที่สร้างมันได้ไม่พอ
    • Mojo เจ๋งนะ แต่ไม่เข้าใจว่าทำไมถึงยังยึดติดกับ ความเข้ากันได้ย้อนหลังกับ Python อยู่ มันกลายเป็นตัวฉุดขาตัวเอง
      ข้อเสียหลายอย่างที่นึกถึงใน Kotlin แทบทั้งหมดก็มาจากความเข้ากันได้กับ Java ในกรณีนี้อาจแก้ได้ดีกว่าด้วยวิธีที่ชัดเจนกว่า แต่แนวทางตอนนี้ดูเหมือนถูกกำหนดให้ล้มเหลว
    • ถ้าไม่โอเพนซอร์สก็แทบไม่มีความหมายอะไร นักพัฒนา Python ส่วนใหญ่ยังไงก็คงไม่มา
    • ในมุมนี้มันแทบจะเหมือนพยายามสร้างภาษา Nim ขึ้นมาใหม่

  • มีเขียนไว้ว่า “สัญญาว่าจะเปิดโอเพนซอร์ส Mojo ในฤดูใบไม้ร่วงปี 2026”
    https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced

    • ถ้าได้เห็นซอร์สโค้ดของ โปรแกรม MLIR ระดับล้ำจริงๆ ก็คงดี

  • น่าเสียดายที่ระหว่างนั้น Nvidia ก็ไม่ได้อยู่นิ่ง และได้สร้าง CUDA รุ่นถัดไปชื่อ CuTile สำหรับ Python และในไม่ช้าก็สำหรับ C++ ผ่าน compiler stack ที่คล้ายกันซึ่งอิงกับ MLIR
    ถึงจะไม่มี portability แต่แค่เพราะ Nvidia ผลักดันอย่างจริงจัง, ผสานเข้ากับเครื่องมือพัฒนา, และทำงานร่วมกับโค้ด CUDA เดิมได้ ก็มีโอกาสสูงมากที่จะถูกใช้มากกว่า Mojo
    Tile IR อาจไม่ได้เป็นการตอบโต้ Mojo เท่าไรนัก แต่ใกล้เคียงกับการตอบโต้ Triton มากกว่า โดยเฉพาะเมื่อมองจากมุมว่ามันทำให้เขียน LLM kernel ที่ได้ประสิทธิภาพพอใช้ได้ง่ายแค่ไหน

    • เพื่อไม่ให้ตามหลัง Intel และ AMD ก็พยายามทำอะไรคล้ายๆ กันอยู่เหมือนกัน และ CPython JIT เองก็กำลังกลายเป็นจริงเสียทีหลังจากพยายามมาหลายรอบ
      ยังมีความพยายามอย่าง GraalPy และ PyPy ด้วย
      ความพยายามเหล่านี้ทั้งหมดทำงานบน Windows ได้ในตอนนี้ ซึ่งสำคัญมากในสภาพแวดล้อมบริษัทที่พนักงานส่วนใหญ่ได้รับเครื่อง Windows และใช้ Linux distro เฉพาะฝั่งเซิร์ฟเวอร์
      มันเลยทำให้อดคิดไม่ได้ว่านี่จะลงเอยแบบ Swift for Tensorflow อีกหรือเปล่า
    • จากที่คุยกับนักพัฒนา Tile IR บางคน แรงจูงใจหลักคือการทำให้การเขียนโปรแกรม tensor core พกพาได้ดีกว่า PTX
      นอกจาก feedback จากลูกค้าแล้ว ไม่มีใครบอกว่ามันเป็นการตอบสนองต่ออะไรบางอย่าง
    • หลายคนเข้าใจผิดว่า Mojo เป็นแค่ไวยากรณ์ที่เขียนโค้ด GPU ได้สะดวก และคิดว่าเฟรมเวิร์ก Python ของ Nvidia ก็ทำหน้าที่นั้นอยู่แล้ว
      แต่ CuTile จะรันบน AMD GPU หรือ Apple Silicon ได้ไหมล่ะ? ต่อให้ Nvidia ทำอะไร ยังไง การผูกติดกับผู้ขาย ก็ยังอยู่
    • อยากรู้เหมือนกันว่า CuTile จะมีอิทธิพลมากแค่ไหน

  • ตอนที่ได้ยินเรื่อง Mojo ครั้งแรก ผมนึกว่ามันจะทำให้ เข้ากันได้กับโค้ด Python เดิม
    แต่ในอนาคตอันใกล้นี้มันดูห่างจากเป้าหมายนั้นมาก ถึงจะเรียกข้ามไปมาระหว่าง Python กับ Mojo ได้ แต่ตัว Mojo เองก็ยังรันโค้ด Python เดิมไม่ได้

    • ตอนโปรโมตช่วงแรก นั่นเป็นหนึ่งในประเด็นหลักชัดๆ เลย เขาพูดประมาณว่าแค่เพิ่ม type hint ให้โค้ด Python ก็จะได้ความเร็วเพิ่มขึ้นมาก
      แต่ดูเหมือนพอทำไปจริงๆ ทิศทางก็เปลี่ยน
    • ถ้าจำไม่ผิด เขาเคยโฆษณาด้วยว่าเร็วกว่า Python แบบเทียบเท่าถึง 36,000 เท่า แต่ไม่ได้ทำให้ชัดเลยว่านั่นเป็นไปได้แค่ใน edge case สุดโต่ง
      มันเลยให้ความรู้สึกเหมือนแผนคริปโตแบบ pump-and-dump มากกว่าจะเป็นความพยายามจริงใจในการพัฒนาระบบนิเวศ Python
    • ถ้าดูอย่างระมัดระวังตั้งแต่แรก ก็ชัดอยู่แล้วว่าแนวคิดคือการสร้างภาษาระบบยุคถัดไป
      นำบทเรียนจาก Swift และ Rust มาใช้, เจาะเป้า CPU/GPU/เป้าหมายแบบ heterogeneous, และวาง MLIR ไว้เป็นศูนย์กลางของภาษา
      ขณะเดียวกันก็วางโครงสร้างให้สามารถ embed หรือ extend Python ได้ค่อนข้างง่ายในอนาคต และกรอบการนำเสนอแบบ Python ก็น่าจะช่วยเรื่องการระดมทุนอย่างมากแน่นอน
      Chris Lattner พูดถึงความสัมพันธ์ระหว่าง MLIR กับ Mojo มากกว่าความสัมพันธ์ระหว่าง Python กับ Mojo เสียอีก
    • ตอนแรกโฆษณามาแบบนั้นจริงๆ เขาอยากเป็นอะไรบางอย่างแบบ Kotlin สำหรับ Python แต่ก็เปลี่ยนทิศทางเร็วมาก
      ทั้งเรื่องนั้นและโมเดลการพัฒนาที่ไม่โอเพนซอร์สเต็มตัว ทำให้มันให้ความรู้สึกเหมือน vaporware มาตลอด
    • บนเว็บไซต์เขียนไว้แบบนี้
      Python interoperability: “Mojo สามารถทำงานร่วมกับ Python ได้แบบเนทีฟ ทำให้คุณกำจัดคอขวดด้านประสิทธิภาพในโค้ดเดิมได้โดยไม่ต้องเขียนใหม่ทั้งหมด คุณสามารถเริ่มจากฟังก์ชันเดียว แล้วค่อยๆ ขยายโดยย้ายโค้ดที่สำคัญต่อประสิทธิภาพไปยัง Mojo ตามต้องการ โค้ด Mojo สามารถ import เข้าสู่ Python ได้อย่างเป็นธรรมชาติและแพ็กไปพร้อมกันเพื่อการ deploy ได้ เช่นเดียวกัน ไลบรารีในระบบนิเวศ Python ก็สามารถ import มาใช้ในโค้ด Mojo ได้”

  • Mojo ดูโอเคนะ แต่สำหรับ การคำนวณเชิงตัวเลขประสิทธิภาพสูง ที่ครอบคลุมทั้ง CPU และ GPU ตอนนี้ผมค่อนข้างพอใจกับ Julia
    ถ้าไม่นับเรื่องไวยากรณ์แบบ Python ช่องว่างนี้ก็ดูเหมือนถูกแก้ไปเกือบหมดแล้ว แม้แต่ Python เองก็ยังมีเครื่องมืออย่าง Numba และ Triton ที่ใช้ได้ผลดีกับปัญหาประเภทที่ซับซ้อนน้อยกว่าและเป็นอิสระมากกว่า

  • ถ้าเป้าหมายเดียวกัน Julia ดูสุกงอมกว่า และตั้งแต่ปีที่แล้ว Nvidia ก็พยายามทำให้เครื่องมือ Python กับ C++ ใน CUDA มีความสามารถเท่าเทียมกัน
    ถ้าใช้ Python cuTile JIT compiler ก็สามารถเขียน CUDA kernel ได้เหมือนเขียน Python ล้วนๆ
    AMD และ Intel ก็เดินตามแนวทางคล้ายกัน
    ยังต้องรอดูว่า Mojo จะมาทันเวลาพอที่จะได้การยอมรับในวงกว้างกว่านี้ไหม

    • คำพูดที่ว่า Python cuTile JIT compiler ทำให้เขียน CUDA kernel ด้วย Python ล้วนๆ ได้นั้นไม่ถูกต้อง ตอนนี้ก็ไม่ใช่ Python ล้วน และต่อไปก็คงไม่มีวันเป็น
      “ภาษาถิ่น Python ที่เป็นมิตรกับประสิทธิภาพ” เหล่านี้ เช่น Triton, Pythran, CuTile, Numba, Pycell, cuPy แม้ภายนอกจะดูเหมือน Python แต่แค่ขูดผิวดูก็จะพบว่าไม่ใช่ Python เลย
      มันคือ DSL สไตล์ Python ที่ออกแบบมาให้เหมาะกับการ optimize และ type inference และถ้าใช้จริงจะรู้สึกได้ชัดมาก แต่ละตัวใช้ฟีเจอร์ของ Python ได้หลายอย่าง หรืออาจจะส่วนใหญ่ไม่ได้เลย แต่ก็ยังต้องแบกปัญหาเฉพาะตัวของ Python อยู่ดี
      พูดตรงๆ คือ Python ไม่เหมาะกับประสิทธิภาพและความมีประสิทธิผลโดยเนื้อแท้
      ปัญหานี้ไปไกลกว่าแค่ GIL มาก ทั้ง dynamic typing, reference semantics, monkey patching, object model ที่ dynamic มากเกินไป, CPython ABI, BigInt โดยปริยาย, ระบบโมดูลตอนรันไทม์ ฯลฯ อาจสมเหตุสมผลสำหรับภาษาสคริปต์เล็กๆ แต่แย่มากสำหรับ high-performance computing และประสิทธิภาพ
      แม้แต่ระบบนิเวศ NumPy/SciPy เองก็เกือบจะเป็นการแฮ็กเพื่อเลี่ยงข้อจำกัดของ Python สำหรับ tensor arithmetic แบบ CPU-bound ธรรมดา
      ประสิทธิภาพพื้นฐานของ Python แย่มากจนแม้แต่ลูป for ง่ายๆ ก็ทำให้ Excel ดูเหมือนม้าแข่งได้
      Mojo ต่างออกไป
      แทนที่จะไปแฮ็กบนฐานเดิมที่มีปัญหา Mojo พยายามเริ่มจาก จุดตั้งต้นที่สะอาด
      และมอบ “ประสบการณ์แบบ Python” บนภาษาที่ออกแบบมาดีโดยอิงจากประสบการณ์การออกแบบภาษายุคหลัง ไม่ใช่ Python ที่มีอายุกว่า 30 ปี
      แค่ด้วยเหตุผลนั้นก็หวังให้มันประสบความสำเร็จ

  • ทุกวันนี้ดูเหมือนอย่างน้อยสำหรับบางคน การโฆษณาโดยชูคำว่า AI native ขึ้นมานำหน้ากลายเป็นเรื่องจำเป็น
    แต่สำหรับผมมันชวนให้ขัดใจหน่อยๆ เพราะดูเหมือนเป็นคำที่จริงๆ แล้วไม่ได้พูดอะไรเลย
    คนที่คลั่งไคล้ AI พอจะช่วยอธิบายได้ไหมว่าทำไมคำว่า “เป็นภาษาที่ compile ได้และมี static typing จึงเหมาะอย่างยิ่งกับ agentic programming” ถึงจริง และมันหมายความว่าอะไรกันแน่

    • หลังจาก AI ถูกดันขึ้นมา การเห็นความสิ้นหวังบนหน้าแรกของผลิตภัณฑ์และบริการพวกนี้ก็น่าสนใจมากจริงๆ
      สำหรับผมอันที่ตลกที่สุดคือตอนเปิดหน้าโปรดักต์ของ IBM DB2 แล้วเห็นคำว่า AI database แปะอยู่
      น่าจะหมายถึงว่าถ้าจับข้อผิดพลาดได้มากขึ้นตั้งแต่ตอน compile เอเจนต์ก็สามารถตรวจสอบงานของตัวเองแบบ static ได้เร็วขึ้น โดยไม่ต้องพึ่ง unit test หรือการทดสอบแบบอื่น
    • ปัจจุบัน LLM ถูกฝึกจากคลังโค้ดเก่าจำนวนมหาศาล ดังนั้นในอนาคตอันใกล้มันจะทำงานกับภาษาที่มีฐานอยู่แล้วได้ดีกว่าภาษาใหม่
      โดยเฉพาะภาษาที่มีโค้ดโอเพนซอร์สให้ใช้งานเยอะอย่าง Python ภาษาหน้าใหม่ที่ไม่มีโค้ดเดิมให้เรียนรู้ถือว่าเสียเปรียบมาก
      ดังนั้นถ้าอยากให้ดูเกี่ยวข้องในโลกแบบ “agentic” ก็อาจจำเป็นต้องทำ การตลาดแบบ AI native ที่ดูสิ้นหวังแบบนี้ ว่าจะพอไหมคงต้องให้เวลาเป็นคำตอบ
    • ผมไม่คิดว่าตัวเองเป็นพวกคลั่ง AI แต่ก็ใช้งานมันจริงๆ
      เอเจนต์มักทำงานได้ดีขึ้นเมื่อได้รับ feedback มากขึ้น การตรวจ type ช่วยจับข้อผิดพลาดงี่เง่าได้อัตโนมัติค่อนข้างเยอะ
      แก่นของมันคือโดยทั่วไปแล้ว ยิ่งให้ hint กับเอเจนต์มากเท่าไร ก็ยิ่งดีเท่านั้น
    • ไม่แน่ใจว่าเขาตั้งใจใช้คำนี้ในความหมายไหน แต่ผมเห็นด้วยว่าคำว่า “AI native” กับภาษาประเภทนี้ค่อนข้างไร้ความหมาย
      ส่วนเรื่องการ compile และ static typing นั้น เวลาทำ agentic programming การจับปัญหาได้ตั้งแต่ compile time ช่วยได้มากจริง
      มันทำให้ปัญหาที่ไปโผล่ตอน runtime ลดลง และลดสถานการณ์ที่เอเจนต์แก้ยากด้วย ถึง unit test จะช่วยอุดช่องว่างได้บ้าง แต่ก็ไม่ทั้งหมด
      สิ่งที่ไม่ได้เขียนไว้บนเว็บไซต์คือ Mojo อาจกลับเป็นตัวเลือกที่แย่สำหรับ agentic programming ด้วยซ้ำ เพราะตอนนี้ยังมี ข้อมูลฝึกของ Mojo น้อยมาก
    • นี่คือ “...บนบล็อกเชน” แบบใหม่
      Python+ruff+pycheck และ TypeScript นั้น compile เป็น bytecode ไม่ใช่ machine code และก็ไม่ได้เป็น static type ในความหมายแบบ Rust
      แต่ถึงอย่างนั้นก็ยังเห็นโมเดลสร้างโค้ดที่ใช้ได้จริงค่อนข้างดีในทั้งสองอย่าง
      มันไม่จำเป็นต้อง “compile” แบบเข้มงวดหรือ “static type” อย่างเข้มก็ได้
      สุดท้ายแล้ว AI แค่ต้องการ เครื่องมือที่ดี สำหรับตรวจสอบโค้ดและวนซ้ำได้เร็ว จึงไม่ได้สนใจคุณสมบัติเหล่านั้นมากนัก

  • Modular มีแผนจะเปิดโอเพนซอร์ส Mojo SDK ทั้งชุดรวมถึง compiler ภายในปลายปีนี้
    มีเขียนไว้ว่า “Mojo 1.0 จะเสถียรภายในปลายปีนี้ พร้อมกับการเปิด compiler และการรับประกันเสถียรภาพของภาษา”
    https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-...

  • ผมยังคอยจับตาดู Mojo อยู่เรื่อยๆ พูดตามตรง สิ่งที่ไม่ชอบที่สุดใน Python คือ ไวยากรณ์
    มีคนพูดถึง Julia ไว้ตรงนี้ ซึ่งผมคิดว่าเป็นภาษาที่ดี แต่ข้อความผิดพลาดจาก compiler กับเอกสารไลบรารียังไม่อยู่ในระดับที่คาดหวังจากภาษาที่โตขนาดนั้น
    ผมยังกังวลเรื่องความถูกต้องของบล็อกที่เคยอ่าน และเพราะขนาดไบนารีกับเวลาเริ่มรันครั้งแรก ก็ดูไม่น่าเป็นไปได้ที่จะสร้าง Python module ในรูปแบบที่ผมต้องการด้วย Julia
    ถึงอย่างนั้นก็ยังหวังว่า Mojo จะกลายเป็นตัวเลือกหนึ่งได้ แต่เพราะผมชอบ REPL และชอบความเป็น dynamic ของ Python อยู่แล้ว สุดท้ายอาจไม่ออกไปนอก NumPy เพราะเรื่องประสิทธิภาพเลยก็ได้

    • สำหรับผมกลับตรงกันข้าม สิ่งเดียวที่ชอบใน Python คือไวยากรณ์
      เพราะงั้นผมถึงชอบ Nim มาก ได้ทั้งความเร็วระดับ C, การรันตอน compile time, metaprogramming, ระบบ type ที่ทรงพลัง, และ memory safety ขณะที่โค้ดก็มักสั้นและสง่างามด้วย
      Mojo ก็น่าสนใจ แต่จนถึงตอนนี้ดูเหมือนจะโฟกัสฝั่งแมชชีนเลิร์นนิงมากกว่าการเขียนโปรแกรมทั่วไป และเท่าที่ทราบ compiler ก็ยังไม่โอเพนซอร์ส
    • ผมชอบการออกแบบของ Mojo มาก เพราะมันมี การจัดการหน่วยความจำแบบกำหนดได้แน่นอน จึงเทียบกับ Julia ไม่ได้
      อีกอย่าง Mojo ก็ดูเหมือนจะโฟกัสไปที่การเป็นภาษาที่แข็งแรงระดับอุตสาหกรรมมากกว่า ผมถึงกับช็อกตอนเห็นว่า implementation แรกของ precompilation ใน Julia ไม่มีการทำ file I/O