翻译自:http://legi.grenoble-inp.fr/people/Pierre.Augier/mojo-the-point-of-view-of-a-researcher-using-python.html
Mojo是什么?来自其官方网站的定义:
“Mojo是一种新的编程语言,它通过结合Python语法的优点与系统编程和元编程,弥补了研究与生产之间的鸿沟。使用Mojo,你可以编写比C语言更快、能无缝与Python生态系统交互操作的便携式代码。”
为何选择Mojo页面解释说这种语言是为人工智能(AI)创建的。 Mojo被描述为一种“具有强大编译时元编程功能、集成自适应编译技术、在整个编译流中进行缓存以及其他现有语言不支持特性”的程序设计语言。 它还关注“支持现代芯片架构”并配备了“MLIR开源编译器基础设施”。
"此外,我们决定让Mojo成为Python的超集(即使得Mojo兼容现有Python程序),并采用CPython实现以支持长尾生态系统。如果你是一个Python程序员,我们希望你会立刻对Mojo感到熟悉,并且提供新工具来开发安全且高效率的系统级代码,而这些代码通常需要在Python下面使用C和C++来完成。”
哇,令人印象深刻!但这真的意味着什么呢?作为一名主要使用Python进行科学计算的流体力学研究员,我在Mojo上写了这篇长笔记来调查几个问题:
Mojo到底是什么?它将会变成什么?
Mojo能否对通用科学计算(即不仅限于AI)有所帮助?
何时才能真正使用它?目前还缺少什么?
Mojo的创建者们已经生成了大量信息丰富的材料来介绍他们创新的编程语言,尤其是文档和在LLVM会议上引人入胜的技术演示。尽管有这些宝贵资源,我在网上并没有找到来自其创建者以外来源的深度描述或分析。这促使我提出关于Mojo 的独立观点。
Mojo的开发始于2022年9月。一个非常早期阶段的版本在2023年5月发布,仅供在线尝试。直到2023年9月,Mojo才能在个人电脑上本地使用。截至当前日期,最新版本是在2023年12月发布的Mojo 0.6.0。虽然还处于初级阶段,但已经用Mojo构建了一些令人印象深刻的程序(例如非常快速和便携式矩阵乘法或Llama.mojo比llama.cpp更快)。此外,该语言及其网站都进入了一个使个体能够更好理解未来几个月和几年内Mojo将变成什么样子的阶段。请注意,就在几个月前这并不是情况,并且清楚地表述出Mojo背后项目的实质显然具有挑战性。
回顾编程语言的分类
在研究Mojo是什么以及将会成为什么之前,有益于重新审视一些常见的编程语言类别。
解释型与编译型:传统上,语言被分为解释型(能够直接通过解释器执行,绕过编译)和编译型(需要代码经过一个编译器处理来生成可执行程序)。解释型和编译型语言之间的区别通常取决于使用方式而非固有的语言特性。例如,存在Python“编译器”,并且像Jupyter这样的工具可以实现C++ 的解析。此外,许多现代解析器包含一个动态生成机器码的编译器,在执行期间通过即时 (JIT) 编译进行。值得注意的是,CPython——Python参考实现——历史上缺乏JIT 编辑功能, 但计划在明年引入到CPython 3.13中。其他Python实现版本如PyPy 和 GraalPy 使用 JIT 编辑。
静态与动态:另一方面, 语言可以根据其动态性程度进行描述。动态特性关乎程序在运行期间修改某些方面能力。静态类型意味着在预先设定时间内将变量与特定类型相关联, 而动态类型则意味着变量(或'名称')可以指向任何类型的对象。其他动态特性可能包括为类型/对象添加或更改方法,甚至修改内置函数的能力。Python以其动态性而闻名, 但它也支持静态编码实践, 具有类型稳定性,其中变量始终指向同一类型的对象,并提供了类型注释选项。动态语言的例子包括Julia和R,而C、C++、Rust和Swift则代表静态语言。
为了完整起见,我们还应该提到强或弱类型系统的概念。Python是强类型语言,所以1 + "2"会引发错误。
我们将看到Mojo不能轻易地用这些类别进行分类。Mojo既可以被解析(带有JIT编译),也可以被编译成机器代码。此外, Mojo 是一种静态语言, 但具有动态功能。
警告:仍为封闭源代码且非常年轻
在深入讨论编程语言和Mojo之前,有两个关键方面值得注意。
首先,必须指出的是,Mojo目前是Modular公司指导下的一个封闭源代码项目。他们的目标是通过显著增强这一领域的技术框架来实现人工智能(AI)的货币化。此策略的构建模块包括 (i) 一个新的AI引擎(类似于TensorFlow和PyTorch,但某种程度上与这些解决方案兼容)以及 (ii) 一种新的编程语言——Mojo。虽然Modular声称Mojo并不打算成为商业“产品”,并写道他们“期望开放源码Mojo核心部分,如标准库”[1] ,但该项目目前仍为封闭源代码。我们将在后面更详细地重新审视这个关键问题。
其次,重要的是要承认 Mojo 还处于早期阶段,并且,在我看来,还未准备好被用于 Modular 外部. Mojo 的创造者专注于语言核心和性能.
创建新的编程语言
虽然像Python、C、C++、Java或Javascript这样的旧编程语言继续主导着景观[2][3],但近年来,应用程序设计语言研究领域见证了显著的活动。一波创新浪潮带来了新编程语言的引入(例如Zig, Vlang等)。除了这些老兵和新手外,还有一些成熟的语言(如Go, Rust, Julia和Swift)围绕它们聚集起了活跃的社区。
在这篇笔记中,我们将主要关注Rust、Julia和Swift。由Mozilla基金会支持的Rust始于2006年,并于2010年公开推出,与C++相比带来了值得注意的创新,特别是其借用检查器方面的安全性。这种系统语言已经取得成功,并在关键领域找到应用,如被用于Firefox 的开发。尽管Rust具有很好的品质,但它以陡峭学习曲线而闻名,在科学领域可能不适合快速原型制作。Julia 的开发始于2009年,并在2012年正式发布——十多年前。多年来,Julia 已经成熟并在密集数值计算应用中找到了自己的位置,表现出色。Swift是Apple最新的语言,于2010年开始开发,并在2014年发布第一个版本。Swift在2015年转向开源模型。
2023年开始一种新的编程语言是一种大胆的想法。在由强大和成熟选择主导的环境中,编程语言之间的竞争非常激烈。新语言不仅需要引入与直接竞争对手相比具有优势和特点的新功能,而且还必须在各个其他方面都足够好。采用新语言带来的好处应该超过使用较少已建立语言所带来的成本。此外,在这个领域里,实用性通常胜过纯粹性。“Julia vs Python”的案例非常有趣。Julia 在科学计算领域明显优于Python, 特别是更好地性能和基础设施, 避免了“两种语言问题”。然而, Python 足够好, 有其他优点并且进化得足够快以至于没有明显向 Julia 转变[4]。
创建并建立一种新编程语言是一项艰巨任务. 尽管设计该语音及其解释器/编译器会自然分配到大量资源, 但也需要考虑包括社区建设, 开发者工具, 打包, 库, 文档等其他方面.
我们也要注意,语言的创造、构建和演变是缓慢的过程。这些人类构建物如此复杂,以至于典型的时间尺度更多地是以年计而不是月。在Rust、Julia或Swift等案例中,在项目启动和它们首次公开发布之间经过了几年。然而,Mojo团队选择了早期发布策略,迅速开始他们项目的公众展示。尽管如此,他们仍处于快速且闭源的开发模式中,并拥有一个小而连贯的团队。在短短一年多的时间里取得了令人印象深刻的进步,引发了对该项目未来轨迹的好奇心。
为什么Mojo可以成功
我们为什么要关心这个刚出生的花哨编程语言?在我看来,有一些强有力的理由表明Mojo可能会在未来几年成为突出的语言之一:
Mojo是对计算(科学和AI)现状不佳的一个回应,这种状态被具有明显弱点(当然包括Python和C++,但也包括Julia和Rust)的语言所主导。如果能有一种新语言,在可用性/性能/安全性之间达到更好的平衡,并具备JIT/OAT编译能力以及良好的学习曲线,特别是对于熟悉Python的人来说,那将是一个净改进。
Mojo基于一个伟大的直觉:静态、安全且具有强大动态功能并与Python无缝集成。
Mojo由非常聪明且知名度高的人领导,尤其是Chris Lattner,“LLVM、Clang编译器、MLIR编译器基础设施以及Swift编程语言”的联合创始人(引自他Wikipedia页面)。他在成功且重要开源项目中取得了卓越成绩,增加了相当多信誉。虽然其他杰出个体也参与到 Mojo 的创建中, 但 Chris Lattner 的杰出履历尤其引人注目。
Mojo有非常坚实的技术基础,LLVM和MLIR,“Mojo是第一种专为MLIR设计的主要语言”[ 5 ]。
Mojo似乎有稳定且长期的资金支持,由一个认真公司背书,并与Amazon Web Services (AWS) 和 NVidia建立了合作关系。
驱动 Mojo 创建的动机在 Why Mojo 页面中特别描述。这很大程度上是为了修复AI中使用的技术栈,该栈被Python和C++等语言所主导。这将Mojo定位为解决长期存在的“两种语言问题”的新尝试,这个挑战也一直是Julia关注的重点。然而, Julia 和 Mojo 解决此问题采取了明显不同方式, 在技术本质(稍后讨论)以及他们与 Python 的关系方面都如此。在某种程度上具有挑衅性地说, Julia 及其社区被视为“反对 Python”,而 Mojo 则希望成为 Python 家族中新成员。
当2009年Julia诞生时,Python在科学计算领域内影响力相对较小。Numpy只在2006年才推出,并且Python 2.7直到2010年才发布。在此期间,Matlab占据更加主导地位。因此,Julia的设计更倾向于Matlab,而不是与Python-Numpy紧密对齐。此外, 使用 Julia 构建可从 Python(或 R)使用的包并不方便。“一种语言适用于所有事情”的方法本质上并不合作。相反, 采用针对不同任务使用不同语言的务实策略在构建强大科学 Python 生态系统中已被证明非常有效。这个生态系统利用了C、Fortran、C++以及现在的Rust [6]等后台语言。
尽管Julia很出色,并且在其领域——密集数值计算中有着优秀的生态系统,但它往往显得有些孤立。对于庞大的Python用户和开发者社区来说,投入时间在Julia上可能并不那么吸引人。
Mojo关于与Python关系的替代策略看起来相当合理。引入一个伴侣和补充语言可能会在Python社区内受到热烈欢迎。鉴于Python当前的主导地位和势头(参见下一节),以及语言动态中固有的惯性,这对Mojo在未来十年是一个非常重要的优势。
关于扩展Python可能性的项目
为了更好地理解Mojo,通过探索一些旨在增强Python并解决其弱点的项目来明确它不是什么,这将非常有益。
PyPy和GraalPy:这些项目是Python的更快速替代实现。然而,由于他们在加速依赖CPython C API的包(如Numpy、Matplotlib、Pandas、scikit-learn等)方面面临挑战,因此他们的采用受到限制。
修复Python C API:正在进行努力以解决此限制,并提高替代Python实现的可用性。这包括引入新的HPy C API和一个更雄心勃勃、长期目标导向的倡议,旨在改进CPython C API。
CPython核心开发:CPython核心开发者积极参与各种倡议以通过诸如no-gil, subinterpreters 和 Faster CPython等项目来提升CPython 的性能。2024年底可以使用的CPython 3.13将移除GIL,并基于Copy & Patch方法实施JIT编译器。
Python编译器:已经开发出各种Python编译器(如Pythran、Numba和Mypyc),以加速特定(静态)子集的 Python ,其中一些还扩展支持到 Numpy。
GPU和并行计算:像Codon和Taichi这样的创新项目在Python环境中引入了专为GPU和并行计算量身定制的领域特定语言(DSLs)。
Mojo与这些项目区别开来,因为它是一种真正独立的语言,而不是归类为Python增强或替代实现。
Mojo==Python++?其实完全不同
Mojo网站声明,Mojo的长期目标是成为Python的超集,意味着大多数Python程序应该可以在无需修改的情况下运行。我对此并不那么乐观,但对我来说这并不重要。要运行Python代码,我们反正还有其他好用的Python解释器。我认为一些Python特性对于像Mojo这样的项目并不那么有用,例如支持inspect模块(用于内省),猴子补丁什么都可以(甚至包括语言内建函数)或CPython C API。
无论如何,重要的是要明白当前的Mojo与Python完全不同。它们之间只有少数几个共享内置函数(print、len、range、slice等)和大部分兼容语法(导入、索引、切片、循环、函数定义、上下文管理器, try/except, async/await, 甚至带dunder方法的结构体定义等)。如前所述,Mojo也可以被“解释”并具有一个REPL(可通过mojo命令启动)。但是一些非常重要的 Python 内置类型缺失了 (比如 str , int , float , list , tuple 和 dict ) 并且几乎没有 Python 标准库可供使用. 更深层次而且更重要地,在语义上,这两种语言非常不同。例如,Mojo变量更像C语言的变量而不是Python的变量:在Mojo中,一个名称附着在一个对象上。例如
from memory.unsafe import Pointer
def print_pointer(ptr: Pointer):
print(ptr.__as_index())
def main():
a = 1
p1 = Pointer.address_of(a)
print_pointer(p1)
a = 2
p2 = Pointer.address_of(a)
print_pointer(p2)
# a = "a" # error: cannot implicitly convert 'StringLiteral' value to 'Int' in assignment
打印:
140728977102328
140728977102328
这意味着只有一个整数变量被修改为a = 2的语句就地修改。相比之下,等效的Python代码,类似于,
a = 1
print(id(a))
a = 2
print(id(a))
打印
140163769254128
140163769254160
使得id(2) - id(1)等于32。名字(引用)a首先指向整数对象1。语句a = 2修改的是引用,而不是整数对象。
在Python中,引用无处不在(名称就是引用,列表/元组中的元素都是引用,函数参数作为引用传递)。Mojo并非如此运行,这带来了严重的后果。例如,在Python中 a = "py"; b = a 创建了两个指向一个对象("py")的引用。相反地, a = "mojo"; b = a 在内存中创建了两个位于不同位置的不同对象。
b = "mojo"
p = Pointer.address_of(b)
print_pointer(p)
c = b # <- this really copies the String object "mojo"
p = Pointer.address_of(c)
print_pointer(p)
140720822767840
140720822767856
在这些例子中,对比变得明显,因为Mojo为开发者提供了与内存中的对象更直接的交互。不同于Python和Julia,Mojo并未使用引用计数和垃圾收集器。相反,像Rust一样,通过借用检查器自动处理内存管理、定义对象的“生命周期”。然而,Mojo也提供了编写类似C语言代码的灵活性,采用指针以及明确分配和释放内存。总之,很明显地看出Mojo主要是一个新颖的静态语言,并从C++、Rust和Swift中汲取灵感。这种语言是专门为安全系统编程设计的。
在Mojo中的引用和动态性?
读到这样一种语言,其基本语义(例如等号运算符的含义)如此不同,却将成为Python的超集,这非常令人惊讶。然而,我们可以在Mojo中实现像Python引用那样行为的对象。事实上,在Mojo中已经有一个重要类型叫做对象,它就是以这种方式行动的,所以这段代码会像在Python中一样执行:
def modify(a):
# argument given by copy in Mojo `def` but one can modify the referenced list
a[0] = 1
def main():
a = object([0])
b = a # <- the reference is copied but not the pointed list
print(a) # prints [0]
modify(a)
print(a) # prints [1]
print(b) # prints [1]
请注意,这是纯粹的Mojo代码,不使用Python解释器。还要注意,默认情况下对象是没有类型注解的参数的类型。最后,请注意,在Mojo中也可以实现一个引用对象(使用引用计数)。我不知道是否在内部为对象(记住,Mojo仍然是闭源)使用了引用计数,或者借检查器足以模拟Python行为而无需引用计数和垃圾收集器。无论如何,由于在Mojo中名称与对象相关联,所以模仿Python需要引用对象。看到两种行为都可以在同一语言中获得很有趣。
内建引用和可变引用
Mojo提案表明,Mojo将有两个关键字ref和mutref。
为了更多的控制和严格的静态代码,增加了更多复杂性¶
如前所述,Mojo从C++、Rust和Swift等静态语言中吸取了重要影响。这种影响引入了一种完全不存在于Python中的复杂性。
三种不同类型的变量,在变量级别上实现不可变性
在Python中,不可变对象和可变对象之间的区别基于它们的类型。在Mojo中,类似于其他静态语言,可以明确标记变量为不可变(let)或者可变(var)。例如,即使Mojo 的字符串本质上是可改动的, 也可以用像 let s = String("Mojo") 这样的语法声明一个不可改动字符串。
此外, Mojo 引入 alias 关键字来定义编译时期常数. 注意, 在编译时期你可以运行任何有效 Mojo 代码. 示例:
alias PI = 3.141592653589793
alias TAU = 2 * PI
执行两次和两种类型的参数
有趣的是, alias 不像C宏(即导致简单的代码替换)。在Mojo中,实际上有两种执行方式:编译时和运行时。函数和结构可以参数化,意味着它们可以具有标准的运行时参数和编译时参数(在Mojo中称为“参数”)。例如,在这里, a 是一个参数, b 是一个参数:
fn bar[a: Int](b: Int):
print("bar[a: Int](b: Int)")
这与C++或Rust的特性非常相似,但有趣的是,可以在编译时运行任何Mojo代码。修饰符 parameter 可以用于定义编译时 if 和函数:
@parameter
if ...:
...
@parameter
fn my_closure[size: Int]():
...
关于一些当前和未来的Mojo特性的评论
编译时元编程
元编程是处理代码的代码。一种语言可以具有帮助开发者写出理解/修改其他代码片段的元编程能力。Mojo文档中的一个部分很好地比较并讨论了不同语言中的不同元编程策略。
例如,Python在其标准库中有模块用于处理Python代码,特别是inspect和ast以及可能替换函数和类(装饰器)的机制。在Transonic中,我们使用这些功能来隔离有用的代码,生成新文件并将它们(在编译时)进行编译,然后在运行时将函数替换为他们已经被优化过且已经被编辑过得等效物。
Julia拥有另一个强大的元编程概念称为宏。Julia宏与函数操作相似但是在解析代码期间执行。这类似于Python装饰器,但区别在于Julia宏可以接受任何表达式作为输入,并非仅限于函数或类定义。此外,他们会根据参数值基础上对条件进行操作。
值得注意地是, Mojo具备(并将增加更多) 编译时间内置程序设计能力. 使用当前版本 (0.5.0) 的 Mojo, 它主要涉及到
(i)带有编译时参数(在Mojo中称为“参数”)的参数化函数和结构
(ii)运行任意的Mojo代码(在编译时)以确定参数值,以及
(iii)基于参数值使用条件。
此外, Mojo 将具备 "静态装饰器, 这些是在编译时间执行并且能够检查和修改 IR 的功能"[7]. 虽然与 Julia 或 Rust 宏类似, 但此特性操作层次更低, 操作 MLIR 中间表示而非源代码.
针对MLIR编译器框架的高级语言
什么是MLIR?来自其维基百科页面
MLIR(多层次中间表示)是一个统一的软件框架,用于编译器开发。 MLIR可以最优化地利用各种计算平台。
中间表示(IR)是人类编程语言和处理单元机器代码之间的语言。 编译器通常在 IR 级别进行优化。据我了解,MLIR似乎是一个超级 IR 框架,具有不同的“方言”和不同的目标(如 CPU、GPU等处理单元类型)。随着各种加速器和异构处理单元使用越来越普遍,预计 MLIR 的重要性将日益增加。 MLIR 是非常新颖的,并且还没有设计出专门用于它的高级语言。 Mojo 创建者之一的目标就是创建这样一种语言:“Mojo 是第一个专为 MLIR 设计的主要语言”[ 5 ] 。 一个专门的 Mojo 教程探讨了这个特性。
内置Python集成
使用Python解释器运行Mojo Python代码非常容易,特别是为了使用任何Python包。在像这样导入包之后,
from python import Python
np = Python.import_module("numpy")
人们可以直接在Mojo中编写Python!由于Mojo底层使用CPython,因此以这种方式在Mojo中执行Python并不比使用CPython快!
正如预期的那样,鉴于Mojo当前的状态,有些事情无法工作,例如用关键字参数调用一个Python函数,在某些包(例如Pandas)中相当烦人!将Python对象转换为Mojo对象仍然相当困难。我想这会很快得到改善.
C 互操作性
Mojo应能够无缝地使用C库,只需像从"math.h"导入cos函数一样。对于科学计算,我们需要在Mojo中有类似于mpi4py或h5py的包,以分别使用MPI和hdf5。
Mojo在科学计算中真正可用还缺少什么?
开源性质
除了技术考虑,Mojo的开源性问题也需要引起关注。尽管Mojo仍然是闭源的,但在Modular之外建立一个强大的社区面临着相当大的挑战。为了促进更广泛的采用,对于Modular来说,在Mojo达到更成熟状态后将其转变为开源模型至关重要。开放源代码化Mojo并为该项目建立透明的治理结构是至关重要的步骤,尽管它具有显著的技术优点,但这些步骤对于Mojo实现其全部潜力和取得广泛成功至关重要。
值得注意的是,“我们期待随着时间推移将 Mojo 的核心部分(如标准库)进行开源”的FAQ中声明,并没有绝对清晰。由“核心部分”这个词组产生了歧义,使人不确定是否某些必要组件会保持闭源状态。在我们等待进一步详细信息时,“ Mojo 的核心部分”这样更清晰地陈述可能会提供更多安慰。一些“ Mojo 扩展”保持闭源可以接受,但如果任何核心组件保持专有,则给用户和社区带来依赖性和不确定性。从我的角度看,如果需要闭源元素,Python社区可能会犹豫是否采用Mojo。尽管承认Mojo需要作为一个闭源项目成熟,但Modular的计划也有必要澄清。我不明白如果按照FAQ中建议的计划(即长期保持 Mojo 的核心部分专有),Mojo如何真正与广泛采用的开源语言竞争。
静态语言的核心
我首先提到Mojo路线图中列出的几个优先事项。
- 所有权和生命周期,特别是对于安全引用(无指针)。
- 扩展traits支持,
- 像Rust那样的代数类型枚举。
预计这些计划中的增强功能将在未来几个月内得到实质性实施,从而导致语言发生重大变化。因此,我们需要在2024年春季重新审视Mojo,以更好地评估其演变和潜力。
更高级别的Python
我认为Python开发者至少需要模仿Python str、list和dict 的Mojo类型。请注意,同类列表和字典(以及其他Python标准库API)正在第三方仓库中实现。
与Python互操作性
能够使用关键字参数调用Python函数(对于Python包的API非常常见,例如Pandas/Polar)
更多从 Python 到 Mojo 的转换 (例如 Numpy 数组到 Mojo Tensor),无需编写 MLIR 代码。
打包
Mojo需要一个好的打包解决方案(也许通过与PiPY和/或Anaconda.org兼容?),并配备像pdm、Pixi或Cargo这样好用的工具。
从Mojo代码生成Python扩展的生产
直接从Mojo代码编译Python扩展,可能通过@export装饰器和像mojo build-py-ext这样的命令,看起来是一个可行的未来前景。使用新的HPy API将是一个合理的选择。值得注意的是,这个潜在功能目前还没有出现在Mojo网站上。然而,从Mojo团队那里获得他们对此功能观点的洞察将会很有趣,因为它对于提高Python社区内部采用率至关重要。
结论
正如我们所探讨的,Mojo的一个独特之处在于它允许开发者编写类似Rust的静态、安全代码。同时,Mojo支持可能缺少类型注解的动态代码,类似于Python。虽然这两个方面仍在不断演变和改进,并将在未来几个月/年中得到提升,但重要的是要认识到即使Mojo旨在成为Python的超集,也不应简单地被视为“Python++”。相反,更准确地说,应该把Mojo看作是一种新型现代静态语言,受C++、Rust和Swift强烈影响,并强调性能、可移植性以及编写适用于异构硬件通用代码的能力。只有这样才能欣赏到Mojo还提供了JIT编译带来的可解释性、内置动态类型代码功能以及成为Python近乎超集的潜力。
我们观察到Mojo与Cython存在相似之处并且显著偏离Cython, Cython是一种具有C功能并作为Python超集运行语言。与 Mojo 不同, Cython 代码需要转换为 C 并不能独立于 Python 解释器运行. Cython 在数值 Python 堆栈中成功采用了许多包,如 scikit-learn。然而,其使用仍局限于这种专门的利基应用。如果能够从Mojo代码中创建Python扩展,那么Mojo可能成为Cython的有力替代品。
Mojo当前的发展轨迹表明它正在被打造为长期成功。Modular设想构建一种强大的编程语言,在未来几十年内蓬勃发展,并将Mojo定位为与已经确立、成熟且完全开源语言相抗衡的强大竞争者。然而,关于 Mojo 解释器/编译器未来许可证方面存在不确定性, 尤其是核心组件可能保留为闭源部分, 这引起了对这些雄心壮志兼容性的担忧。
Mojo团队正按计划在接下来几个月内交付一种出色的高性能计算语言。鉴于到目前为止所见证到的显著进步,我们有理由预期到2024年底时,Mojo将技术上健全无误,并具备改进后生命周期管理、类似Rust风格Enum、Python兼容性等特点。
关于是否使 Mojo 的核心完全开源这个重要决策带来了重大影响. 如果完全开源, Mojo 可以产生变革性的影响, 尤其是在 Python 社区. 这种情况需要 Mojo 团队投入资源,使得从Mojo代码生成Python扩展成为可能。由此产生的开源动力可能会迅速提升Mojo生态系统,促进大量新库的开发。相反,如果 Mojo 的核心部分仍然保持闭源状态,则采用率可能会降低,许多人可能选择其他开源解决方案。值得注意的是,在我向经验丰富、高度合格的开发者介绍Mojo时,他们最初常常关注它的闭源状态以及未来是否将转为开源状态。
我倾向于对Mojo未来的开源性质持乐观态度,因为这符合Mojo和Modular的利益。Mojo仍然是一个正在封闭源代码巢中成长的小鸟。我们希望,在未来几年里,Mojo将展翅高飞,在协同开发的上升气流中与其著名的开源同行并驾齐驱。
总结一下,我想分享一下我对Mojo非常个人化的印象。作为一个有静态语言和高性能计算经验的Python开发者,使用和探索Mojo给了我既愉快又富有智慧刺激感的体验。它让我有种在家、在假期,并且同时拥有超能力的感觉。
[ 1 ]
https://docs.modular.com/mojo/faq.html#open-source
[ 2 ]
https://www.tiobe.com/tiobe-index/
[ 3 ]
https://madnight.github.io/githut
[ 4 ]
https://twitter.com/mhsatman/status/1724872548532334726
[ 5 ] ( 1 , 2 )
https://docs.modular.com/mojo/why-mojo.html#mlir
[ 6 ]
https://www.pola.rs/
[ 7 ]
https://docs.modular.com/mojo/roadmap.html#full-mlir-decorator-reflection