- Chris Lattner เป็นผู้พัฒนาหลักของ LLVM และภาษา Swift และกำลังพัฒนาภาษาใหม่ชื่อ Mojo เพื่อดึง ประสิทธิภาพ ของฮาร์ดแวร์ ML รุ่นใหม่ออกมาใช้ให้ได้สูงสุด
- Mojo มีเป้าหมายเป็นภาษาที่ให้ทั้งความใช้งานง่ายและการควบคุมรายละเอียดฮาร์ดแวร์ โดยใช้ เมตาโปรแกรมมิงที่ปลอดภัยด้านชนิดข้อมูล เพื่อช่วยจัดการรายละเอียดของฮาร์ดแวร์ได้อย่างมีประสิทธิภาพ
- เบื้องหลังสำคัญคือการแก้ปัญหา การแตกแยกของระบบนิเวศ AI accelerator เช่น GPU, TPU, ASIC และการสร้าง แพลตฟอร์มคอมพิวติ้งแบบรวมศูนย์ เพื่อลดการพึ่งพาผู้ขายรายใดรายหนึ่ง
- เนื่องจากสแตกซอฟต์แวร์ GPU ที่มีอยู่เดิม (CUDA, ROCm, XLA ฯลฯ) มีปัญหาทั้งด้านความเข้ากันได้และ ความซับซ้อน การพัฒนาภาษาแห่งอนาคตที่ทั้งประสิทธิภาพสูงและพกพาได้จึงเป็นสิ่งจำเป็น
- Modular กำลังผลักดัน โมเดลธุรกิจ ที่เปิดให้ Mojo ใช้งานฟรี และมุ่งแก้ปัญหาจริงผ่านการรองรับฮาร์ดแวร์แบบรวมศูนย์และบริการสำหรับองค์กร
แนะนำ Chris Lattner และเส้นทางอาชีพ
- Chris Lattner มีประสบการณ์นำโครงการสำคัญในวงการคอมพิวติ้งหลายโครงการ เช่น LLVM, Clang, MLIR, Swift และ Mojo
- เขาเคยทำงานกับองค์กรหลากหลายแห่ง เช่น Apple, Tesla, Google, SiFive และ Modular ทำให้มีประสบการณ์ภาคสนามอย่างกว้างขวางในด้าน คอมไพเลอร์และการออกแบบภาษาโปรแกรม
- ในช่วงแรก เขาเริ่มต้นจากภาษาง่าย ๆ อย่าง BASIC และสภาพแวดล้อม PC ก่อนจะสนใจเรื่อง การดึงประสิทธิภาพฮาร์ดแวร์ออกมาให้สูงสุด ผ่านเกมและกราฟิก
- ช่วงมหาวิทยาลัย เขาได้รับอิทธิพลจากอาจารย์ด้านคอมไพเลอร์โดยบังเอิญ และได้ค้นพบเสน่ห์ของระบบและ สถาปัตยกรรมซอฟต์แวร์ขนาดใหญ่
เดินข้ามไปมาระหว่างคอมไพเลอร์และการออกแบบภาษา
- Chris Lattner มีประสบการณ์ทั้งด้าน วิศวกรรมคอมไพเลอร์และการออกแบบภาษา และสร้างผลงานเด่นจากจุดตัดของสองด้านนี้
- ตัวอย่างเช่น LLVM เป็นภาษาเชิงกลางที่หลายภาษาสามารถใช้งานได้ และก่อให้เกิดการประยุกต์ใช้อย่างกว้างขวาง ไม่ใช่แค่ใน C++ แต่รวมถึง Rust, Julia และอื่น ๆ
- การพัฒนา Swift เองก็เริ่มจากความพยายามจะก้าวข้ามข้อจำกัดและความเหนื่อยล้าจากการใช้งาน C++ เดิม พร้อมให้ความสำคัญกับ ฟีเจอร์ที่ใช้งานได้จริง เช่น pattern matching
- เขาชอบแนวทางการออกแบบนวัตกรรมภาษาโปรแกรมที่ตั้งอยู่บน การแก้ปัญหาจริงและประโยชน์ใช้สอย มากกว่าทฤษฎีทางคณิตศาสตร์
ทฤษฎีภาษาโปรแกรมและความเป็นจริงในการใช้งาน
- Chris มุ่งเน้นวิธีคิดแบบ แก้ปัญหาเป็นศูนย์กลาง มากกว่าความเคร่งครัดทางคณิตศาสตร์ และเมื่ออ่านงานวิจัยด้าน PL เขาจะสนใจตัวอย่างเชิงปฏิบัติและกรณีใช้งานมากกว่าตัวทฤษฎีเอง
- เขายอมรับว่าฟีเจอร์ภาษาที่มีพื้นฐานคณิตศาสตร์แข็งแรงมีข้อดีในด้าน ความสอดคล้องและความสามารถในการประกอบรวมกัน แต่แรงผลักดันของการนำไปใช้จริงคือประโยชน์ที่ผู้ใช้มองเห็นได้ชัด
- เขากล่าวว่าภาษาใหม่หรือเทคโนโลยีใหม่ควรถูกออกแบบให้ลด "เม็ดทรายแห่งความซับซ้อน (grain of sand)" ให้มากที่สุด เพื่อมุ่งสู่ความเรียบง่ายและการขยายตัวได้ดี
ปัญหาเชิงโครงสร้างของระบบนิเวศฮาร์ดแวร์ AI
- เดิมที โครงสร้างพื้นฐานคอมไพเลอร์ (LLVM) มุ่งเน้น CPU เป็นหลัก แต่ AI/แมชชีนเลิร์นนิงต้องการ ฮาร์ดแวร์เฉพาะทาง ที่หลากหลาย เช่น GPU, TPU, ASIC และ FPGA
- ผู้ขายแต่ละรายต่างพัฒนา สแตกซอฟต์แวร์เฉพาะของตัวเอง (CUDA, ROCm, XLA ฯลฯ) ซึ่งนำไปสู่ การขาดความเข้ากันได้และการแตกแยกของระบบนิเวศ
- ซอฟต์แวร์ ML (เช่น PyTorch) ต้องมีการปรับแต่งแยกตามผู้ขายฮาร์ดแวร์ ทำให้การดูแลรักษาและการขยายระบบทำได้ยากมาก
- เพราะแต่ละฮาร์ดแวร์มี สแตก ภาษา และระบบนิเวศเครื่องมือที่ต่างกัน นักพัฒนาซอฟต์แวร์จึงเผชิญกับปัญหาผลิตภาพต่ำและการพกพาที่ลดลงอย่างแพร่หลาย
บทบาทของ Modular และ Mojo
- ทีม Modular มุ่งสร้าง แพลตฟอร์มซอฟต์แวร์แบบทั่วไปและแบบรวมศูนย์ เพื่อแก้ปัญหาเหล่านี้
- Mojo ถูกออกแบบมาโดยตั้งเป้าทั้ง การรีดประสิทธิภาพจากสถาปัตยกรรม GPU สมัยใหม่ เช่น tensor core และการ เขียนเคอร์เนลที่พกพาได้ ข้ามฮาร์ดแวร์หลายชนิด
- ด้วยโครงสร้างหลายชั้นอย่าง Mojo, MAX (เช่น การเสิร์ฟ LLM ประสิทธิภาพสูง) และ Mammoth (การจัดการคลัสเตอร์/Kubernetes) ทำให้สามารถให้โครงสร้างพื้นฐาน AI แบบบูรณาการได้
ที่มาของความจำเป็นต่อ Mojo และการตัดสินใจด้านการออกแบบภาษา
- ภาษาที่มีอยู่เดิมไม่สามารถตอบโจทย์ทั้ง ความพกพาของเคอร์เนล ML ประสิทธิภาพสูง และ การปรับแต่งเฉพาะผู้ขาย ได้พร้อมกัน
- Mojo จำเป็นต้องรับมือกับ รายละเอียดเชิงโครงสร้างของฮาร์ดแวร์ ได้แบบยืดหยุ่น เช่น ชนิดข้อมูลต่าง ๆ (เช่น 8-bit floating point) และฮาร์ดแวร์ที่เปลี่ยนแปลงรวดเร็วอย่าง tensor core
- โมเดล เมตาโปรแกรมมิงที่คงความปลอดภัยของชนิดข้อมูล ช่วยแปลงการควบคุมฮาร์ดแวร์ที่ซับซ้อนให้มีประสิทธิภาพขึ้น และทำให้การแบ่งปันโค้ดทำได้ง่ายขึ้น
การเปลี่ยนแปลงของการออกแบบฮาร์ดแวร์และเคอร์เนล
- CPU ในดาต้าเซ็นเตอร์ยุคใหม่ขยายไปสู่หลายคอร์ ขณะที่ GPU พัฒนาอย่างรวดเร็วด้วยสถาปัตยกรรมที่ออกแบบมาเพื่อ การประมวลผลแบบขนาน เช่น SM (Streaming Multiprocessor) และ Warp (การทำงานของ 32 เธรด)
- เมื่อมีการนำหน่วยประมวลผลเฉพาะ AI อย่าง tensor core เข้ามาในฮาร์ดแวร์ ก็จำเป็นต้องมี กระบวนทัศน์การเขียนโปรแกรมฮาร์ดแวร์ แบบใหม่ที่ต่างจาก CUDA แบบดั้งเดิมโดยสิ้นเชิง
- แม้จะเป็น ผู้ขายรายเดียวกัน ก็ยังมีการเปลี่ยนแปลงด้านความเข้ากันได้ระหว่างสถาปัตยกรรมแต่ละรุ่นอยู่บ่อยครั้ง (เช่น Nvidia Volta/Hopper/Blackwell) ทำให้สแตกซอฟต์แวร์ตามไม่ทัน
โมเดลธุรกิจและกลยุทธ์ระบบนิเวศแบบเปิด
- Modular ไม่ได้มุ่งขายตัวภาษาโดยตรง แต่เปิดให้ใช้ Mojo ฟรี
- โมเดลรายได้หลักอยู่บนการให้ แพลตฟอร์ม/บริการ สำหรับองค์กร รวมถึงการจัดการฮาร์ดแวร์แบบรวมศูนย์
- ด้วยแนวทางนี้ บริษัทต้องการท้าทายการสร้าง ระบบนิเวศสาธารณะ ที่ไม่ถูกล็อกกับผู้ขายรายใดรายหนึ่ง พร้อมรองรับฮาร์ดแวร์ที่หลากหลายและการจัดการโครงสร้างพื้นฐานอย่างมีประสิทธิภาพไปพร้อมกัน
บทสรุป
- โครงการ Mojo ของ Chris Lattner และ Modular มีความสำคัญในฐานะความพยายามสร้าง ภาษาโปรแกรมและแพลตฟอร์มใหม่ เพื่อรองรับความก้าวหน้าของแมชชีนเลิร์นนิง นวัตกรรมฮาร์ดแวร์ AI และการก้าวข้ามการแตกแยกของระบบนิเวศ
- ด้วยการออกแบบภาษาที่สร้างสรรค์และการผลักดันระบบนิเวศแบบเปิด กลยุทธ์นี้มีเป้าหมายช่วย ทำให้ระบบนิเวศ AI เป็นประชาธิปไตยมากขึ้น และเพิ่มผลิตภาพโดยรวม
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
อยากขอบคุณทุกคนที่ให้ความสนใจทั้ง Mojo และพอดแคสต์ หากอยากรู้เกี่ยวกับ Mojo มากขึ้น สามารถดูคำถามที่พบบ่อยได้ที่ FAQ (มีคำตอบเรื่อง “ทำไมไม่ทำให้ Julia ดีขึ้นไปเลย” ด้วย) เอกสารก็อ่านได้ที่ ที่นี่ และ ซอร์สโค้ดโอเพนซอร์ส ก็เปิดเผยแล้วในระดับหลายแสนบรรทัด ชุมชน Mojo ก็ยอดเยี่ยมมากเช่นกัน ถ้าสนใจก็มาร่วมกันได้ที่ ฟอรัม Discourse หรือ แชต Discord - เป็นความเห็นจาก Chris Lattner
ขอประกาศตัวว่าเป็นแฟน ผมดูหลายงานนำเสนอเกี่ยวกับ Mojo มาแล้ว และแม้จะได้ยินว่า Mojo ใช้เทคโนโลยีคอมไพเลอร์ล้ำสมัย แต่ยังไม่เคยเห็นตัวอย่างที่เป็นรูปธรรมเลย แม้คนที่ไม่ใช่นักพัฒนาคอมไพเลอร์จะเข้าใจได้สัก 20% ก็ยังอยากสัมผัสให้เห็นว่าความล้ำสมัยนั้นเป็นอย่างไร จึงอยากให้เขียนบล็อกโพสต์ที่ลึกและเทคนิคจริงจังมากสักชิ้น
ใน FAQ มีคำถามว่า "Mojo Playground ยังใช้งานได้หรือไม่?" แล้วพาไปยัง Playground นั้น แต่พอเข้าไปกลับมีข้อความว่า 'Playground จะถูกถอดออกในรีลีส 25.6 ถัดไป' การตอบ FAQ เรื่อง 'ยังใช้ได้ไหม' ด้วยฟีเจอร์ที่กำลังจะถูกถอดออก ดูเหมือนพลาดประเด็นไปนิดหน่อย คำตอบที่แท้จริงน่าจะเป็น 'ใช้ได้อีกไม่นาน'
Chris ยินดีที่ได้เจอคุณที่นี่ ผมเคยลงทุนผ่าน Light Table มาก่อน เลยสงสัยว่ามีอัปเดตอะไรไหม (ไม่ได้ถามจริงจังนะ แค่ Mojo ดูเท่มาก) ผมสงสัยเรื่องความยั่งยืนระยะยาวของโครงการแบบนี้ และมีหลักฐานที่น่าเชื่อถือรองรับหรือไม่
ที่ Python ครองวงการ ML ได้ เป็นเพราะแอปพลิเคชัน ML สมัยใหม่ไม่ใช่แค่สคริปต์คำนวณธรรมดา แต่ต้องการความสามารถที่กว้างขวางและระบบนิเวศที่แข็งแรง ทั้งการเตรียมข้อมูลแบบต่าง ๆ (ETL) การจัดการข้อมูลหลายรูปแบบ การประมวลผลแบบกระจายบนคลัสเตอร์สมรรถนะสูง การทำ visualization และการเชื่อมต่อ GUI/DB ล้วนมี Python เพียงภาษาเดียวที่ครอบคลุมทั้งหมด ส่วนงานคำนวณเชิงตัวเลขนั้น NumPy, PyTorch, JAX ฯลฯ ก็ใช้ C/C++/FORTRAN ภายในอยู่แล้วจึงเร็วมาก และโค้ดที่ต้องการสมรรถนะสูงก็แยกไปเขียนเป็น C/C++ ได้ง่าย ระบบ C/C++ FFI ของ Python ก็ใช้งานได้จริงเพียงพอเมื่อเทียบกับภาษาอื่น การทำแบบนี้มีข้อดีกว่าการไปสร้างระบบนิเวศทั้งหมดใหม่ในภาษาอื่นอย่าง Julia มาก
ระบบนิเวศของ Python ไม่มีใครเทียบได้ก็จริง แต่การจับคู่ Elixir/Nx ก็ทำหลายอย่างที่ Mojo สัญญาไว้ได้แล้ว ผ่าน EXLA ก็คอมไพล์ลง GPU/TPU ได้ ใช้ Explorer/Polars ทำงานด้าน data frame ได้ และใช้ Pythonx ฝังไลบรารี Python ได้ด้วย ความต่างคือ Elixir ถูกออกแบบมาเพื่อระบบกระจายตั้งแต่ต้น ทำให้ BEAM/OTP รับคำขอพร้อมกันจำนวนมหาศาลและประสานงานระหว่างโหนด GPU ได้เช่นกัน ถ้าจะสร้างบริการ ML จริง ๆ การมีสแตกที่แข็งแรงตั้งแต่ Phoenix, LiveView ไปจนถึง Nx ซึ่งให้ทั้งความทนทานต่อความผิดพลาดและการขยายระบบขั้นสูง อาจสำคัญกว่าประสิทธิภาพฮาร์ดแวร์ที่ดีกว่าเพียงเล็กน้อย
ผมมองต่างออกไปนิดในฝั่ง inference การลงไปปรับแต่ง CUDA kernel โดยตรงนั้นทำได้ไม่ยาก และ CUTLASS 3 รุ่นล่าสุดหรือ C++ สมัยใหม่ก็สะดวกขึ้นมาก Torch ที่วางทับอยู่ด้านบนค่อนข้างบาง แต่ส่วนนี้กลับทั้ง build ยากและเพิ่มความซับซ้อนจากหลายปัญหา เช่น reference counting แก่นแท้จริง ๆ อยู่ที่ kernel ชั้นล่าง และผมคิดว่าอีกไม่นานจะถอดส่วน ‘torch cover’ พวกนี้ออก แล้วเชื่อมเข้ากับโปรแกรม C++ ที่สะอาดและชัดเจนโดยตรง
ปัญหานี้เป็นเรื่องการกังวลกับ GPU kernel ซึ่ง kernel แบบนั้นแต่แรกก็ไม่ได้เขียนด้วย Python อยู่แล้ว Python เป็นภาษา ‘กาว’ สำหรับ ML ผมเห็นด้วยกับคำกล่าวที่ว่า “มีแต่ Python ที่มีทุกอย่างครบ” แต่ก็ยังเสียดายนิดหน่อยที่ระบบนิเวศเติบโตโดยมี Python เป็นศูนย์กลาง แทนที่จะเป็นภาษาที่ดีกว่า
การที่ Python กลายเป็นภาษาหลักของ ML เป็นผลจาก ‘วงจรส่งเสริมตัวเอง’ มันถูกเลือกไปแล้ว ระบบนิเวศจึงเติบโตขึ้นก็จริง แต่เหตุผลที่ถูกเลือกตั้งแต่แรกยังต้องอธิบายแยกต่างหาก ทุกวันนี้มันใหญ่จนดูเหมือนไม่มีทางล้มได้แล้ว แต่จะใช้สิ่งนี้มาอธิบายว่าทำไมถึงเป็น Python ตั้งแต่ต้นก็ยังไม่พอ
น่าแดกดันที่ Python เป็นภาษาที่แย่ที่สุดสำหรับงานทุกอย่างที่พูดถึงนั้น ทั้ง packaging และไบนารีแบบ wheel ล้วนสร้างความเจ็บปวด และมักมีอะไรพังอยู่เสมอ มันโอเคสำหรับสคริปต์เดี่ยว ๆ แต่ถ้าคุณออกแบบ Python มาโดยตั้งใจให้เป็นภาษาหลักของ ML ก็ไม่มีใครอยากให้มันออกมาเป็นแบบนี้แน่
ผมฟังตอนนั้นแล้วตกใจมาก ที่บอกว่าแม้จะถึงเดือนกันยายน 2025 การรองรับ class ก็ยังเป็นเป้าหมายระยะกลางอยู่ น่าประหลาดใจมาก แต่ก่อน Mojo ถูกโปรโมตบ่อยมากว่าเป็น ‘superset ของ Python’ แต่จากความคืบหน้าปัจจุบัน มันดูเหมือนยังเป็นเพียงเป้าหมายในอุดมคติ
ความจริงแล้วไม่เคยมีช่วงไหนที่ ‘superset ของ Python’ เป็นเป้าหมาย มันเป็นแค่สโลแกนเรียกความสนใจ ช่วงแรกพูดหนักหน่อยแล้วก็เงียบ ๆ เลิกพูดไป
ผมสงสัยว่าอาจไม่ใช่เรื่องความเร็ว แต่อาจเป็นเพราะพวกเขาไม่ชอบ OOP เองมากกว่า
มันเป็นเป้าหมายระยะยาวมาโดยตลอด
อาจเป็นคำถามที่ค่อนข้างคลาสสิก แต่ผมสงสัยว่าทำไมถึงไม่เลือก Lisp หากสมมติว่าโค้ด ML ในอนาคตสุดท้ายจะถูกเขียนโดยเครื่องจักร (หรือระบบแปลงอัตโนมัติจากภาษาธรรมชาติ) อยู่ดี Lisp S-Expression ก็แทบจะเท่ากับ AST อยู่แล้ว จึงเป็นภาษาที่เป็นธรรมชาติที่สุดสำหรับเครื่อง และสภาพแวดล้อม REPL ก็มักพร้อมใช้อยู่แล้ว ดังนั้นในฐานะตัวแทน Python มันก็ดูเหมาะมาก
Yann LeCun และคนอื่น ๆ เคยสร้าง Lisp สำหรับ ML ชื่อ Lush ในช่วงยุค 2000 มันยอดเยี่ยมที่สุด และแทบไม่มีทางเลือกอื่นเลยก่อนที่ Python (Theano) หรือ Lua (Torch) จะมา ผมยังอยากให้ทุกวันนี้ Lisp กลับมาได้รับความสนใจอีกครั้ง Python มีไลบรารีที่ยอดเยี่ยม แต่ตัวภาษาเองยังมีส่วนที่ควรปรับปรุงอีกมาก
LLM (โมเดลภาษาขนาดใหญ่) ยังไม่ค่อยเก่งเรื่องการนับวงเล็บ ;)
จากประสบการณ์ที่ Lisp เคยถูกเมินในช่วงบูม AI ครั้งก่อน นักพัฒนาจำนวนมากจึงยังใช้แค่ Emacs + SBCL ทั้งที่จริง ๆ ยังมี Lisp ระดับสูงตัวอื่นอย่าง LispWorks, Allegro, Clozure ด้วย แต่หลายคนไม่เคยได้ลอง
ผมไม่ชอบตั้งแต่เรื่องไลเซนส์ของ Mojo แล้ว
ผมก็ไปดูมาเหมือนกัน ไลเซนส์ของ Mojo ระบุว่ามีการแยกกรณีการใช้งานบน CPU หรือ Nvidia ออกจาก ‘accelerator’ อื่น ๆ (เช่น TPU, AMD ฯลฯ) และถ้าเป็นการใช้งานเชิงพาณิชย์จะต้องมีไลเซนส์แยกต่างหาก ดูบล็อก
ในมุมผม ถ้าภาษาอย่าง Mojo ถูกควบคุมโดยบริษัทใดบริษัทหนึ่งแบบเบ็ดเสร็จ ก็ไม่มีเหตุผลเลยที่จะนำไปใช้ในธุรกิจ มีกรณีตัวอย่างมาแล้วว่าหลายบริษัทเจอปัญหาจากการเปลี่ยนแปลงไลเซนส์ของ Java การเอาธุรกิจไปวางบน Mojo แทน Python จึงเสี่ยงเกินไป
พอดู Mojo FAQ ก็ยิ่งงง เพราะในความหมายเคร่งครัดมันบอกว่ามุ่งไปทางการเป็น superset ของ Python แต่ใน roadmap กลับบอกว่า “จะมอบโค้ดและความคุ้นเคยแบบ Python แต่ไม่สามารถเป็น superset ที่สมบูรณ์ได้” ถ้าเป้าหมายไม่ใช่ความเข้ากันได้กับ Python แล้วจะพูดถึง Python อยู่เรื่อย ๆ ทำไม อีกอย่างผมสงสัยว่ามีเรื่องใช้ emoji เป็นนามสกุลไฟล์จริงหรือไม่
เท่าที่ผมรู้ Mojo ต้องการแค่ syntax สไตล์ Python และการทำงานร่วมกับ Python เท่านั้น การพยายามสื่อว่ามันคล้าย Python ไปมากกว่านั้นเป็นเรื่องการตลาดเสียมากกว่า
เรื่องนามสกุลไฟล์แบบ emoji นั้น จริงครับ เป็น U+2615 (อีโมจิกาแฟ)
ผมอยากรู้ว่า Mojo ดีกว่า Julia ตรงไหน เพราะแม้ Julia จะมีข้อจำกัดด้านอินเทอร์เฟซหรือระบบนิเวศอยู่บ้าง แต่มันก็เชื่อมกับ Python ได้ดีพอแล้ว เลยไม่ค่อยรู้สึกว่า Mojo ดีกว่าอย่างชัดเจน
โดยเฉพาะ Julia มีระบบนิเวศด้าน GPU ที่ดีมาก ทั้ง JuliaGPU และ Reactant ดู Reactant.jl
ความเข้ากันได้กับ Python อาจเป็นจุดที่ Mojo ทำได้ดีกว่านิดหน่อย แต่ในทางปฏิบัติ Julia ก็เรียกใช้ไลบรารี Python ได้ค่อนข้างเสถียรผ่าน PythonCall.jl และเฟรมเวิร์ก ML (Lux.jl, Flux.jl) ก็ทำงานได้ดีภายใน Julia เอง ดูเหมือน Mojo จะยังไม่มี native ML framework ในระดับใกล้เคียงกัน
Mojo ดูเหมือนจะมุ่งไปเป็นภาษาระดับล่างมากกว่า ให้การควบคุมมากกว่า และให้ความแข็งแรงมากกว่า ขณะที่ Julia มีปัญหาเรื่องความหมายหรือประสิทธิภาพที่คาดเดาได้ยาก จึงไม่ค่อยเหมาะจะเป็นฐานของซอฟต์แวร์แกนหลัก ส่วน Mojo เหนือกว่าในจุดนี้
ผมพยายามจะสร้าง Python module ด้วย Julia แต่รู้สึกว่าการรองรับยังไม่พอ ส่วนนี้เป็นฟีเจอร์หลักของ Mojo
Julia ยังขาดความสามารถในการคอมไพล์โค้ดให้เป็น native binary แบบสมบูรณ์จริง ๆ (เหมือน Rust หรือ C++)
ผมรู้สึกว่าการที่ Mojo ยังไม่ได้รับความสนใจมหาศาล และคนก็ยังใช้ PyTorch กันอยู่ อาจเป็นสัญญาณว่าปัญหาเรื่องไลเซนส์ใหญ่กว่าที่คาดไว้มาก
ดูเหมือน Mojo จะประเมินพื้นที่ของตัวเองในตลาดแบบมองโลกสวยเกินไป Julia เองก็มีการใช้งานเชิงพาณิชย์เพิ่มขึ้นเรื่อย ๆ และรองรับ GPU ได้ดี แม้ JIT compiler ของ Python จะยังไม่ดีนัก แต่ Nvidia, Intel และรายอื่นก็ปรับแต่ง GPGPU programming ผ่าน Python DSL ได้มากพอสมควร จนใช้งานใน Python ได้ใกล้เคียงระดับ C++ สุดท้าย Mojo จึงมีจุดแตกต่างไม่มากนัก
จากมุมมองฝั่งระบบ ความพยายามของ Chris และทีมที่ต้องการใช้ Mojo แก้ปัญหา multi-language FFI ให้หมดจดนั้นน่าประทับใจ แต่ตราบใดที่ยังไม่โอเพนซอร์ส ก็ยังเริ่มคุยเรื่องการลงทุนอะไรไม่ได้
มันยังไม่พร้อมสำหรับใช้เป็นภาษาทั่วไปจริง ๆ Modular เองก็เคยพยายามนำ Mojo API ไปใช้กับ MAX engine แต่ภาษาเปลี่ยนเร็วเกินไปจนเลิกลงทุน ตาม roadmap คงต้องรอให้เฟส 1 เสร็จก่อนจึงจะเริ่มมีการนำไปใช้อย่างจริงจัง
ผมยังไม่แน่ใจด้วยซ้ำว่ามันเปิดเผยจริงหรือไม่ จนไม่นานมานี้มันยังไม่เป็นโอเพนซอร์ส ทำให้ลังเลที่จะพึ่งพาซอฟต์แวร์เชิงพาณิชย์แบบปิดผูกขาด
ตอนต้นบทความบอกว่าใช้ ‘kernel ล้ำสมัย’ ได้ สุดท้ายแล้ว Mojo น่าจะพยายามไปแข่งกับ C++ ในการพัฒนา kernel ส่วนใน PyTorch หรือ Julia ปกติแล้วผู้ใช้จะไม่ได้เขียน kernel เอง แต่จะเขียนในระดับสูงเป็นหลัก
มี Lex Fridman พอดแคสต์ตอนที่ Chris Lattner ไปออกรายการ:
ความพยายามทำ Mojo นั้นกล้าหาญและน่าสนใจมาก แต่ถ้ามันเป็นภาษาปิดแบบ Matlab สำหรับผมและอีกหลายคน นั่นคือข้อเสียร้ายแรงที่ตัดออกได้ทันที