Mojo 1.0 beta

(mojolang.org)

3 pontos por GN⁺ 7 시간 전 | 1 comentários | Compartilhar no WhatsApp

Mojo se apresenta como uma linguagem para “escrever como Python, executar como C++” e atualmente oferece a versão estável 1.0.0b1 (May 7)
Seu objetivo é permitir escrever código rápido em diversos tipos de hardware, de CPU a GPU, sem ficar preso a um fornecedor específico, sendo projetada como uma linguagem estática de alto desempenho para sistemas modernos de IA
Oferece interoperabilidade com Python de forma nativa, permitindo mover apenas os gargalos de desempenho para Mojo sem reescrever todo o código existente, e suporta tanto import de código Mojo no Python quanto import de bibliotecas Python no Mojo
É possível escrever kernels de GPU na mesma linguagem, e a metaprogramação em tempo de compilação usando a mesma linguagem do código de runtime busca oferecer otimizações por hardware e abstrações sem custo
A biblioteca padrão do Mojo está totalmente open source no GitHub e aceita contribuições, enquanto o compilador do Mojo tem abertura do código planejada para 2026

Versões e materiais para começar

A versão estável atual é 1.0.0b1 (May 7), e a nightly mais recente é May 9
O Mojo se inspira na sintaxe intuitiva do Python, na segurança de memória do Rust e na metaprogramação em tempo de compilação poderosa e intuitiva do Zig
Como linguagem estática compilada, também é adequada para programação orientada a agentes
Em vez de obrigar a escolher entre produtividade e desempenho, busca entregar ambos, permitindo começar com padrões de programação simples e familiares e adicionar complexidade quando necessário
Como caminhos iniciais, estão disponíveis Install Now, Quickstart, Releases, Roadmap e GitHub
Para ver a página em Markdown, é possível adicionar .md à URL, e o índice completo da documentação do Mojo pode ser consultado em llms.txt

GPU e interoperabilidade com Python

Programação para GPU

O Mojo busca tornar a programação para GPU acessível sem bibliotecas específicas de fornecedor nem código compilado separado
É possível escrever kernels de GPU de alto desempenho na mesma linguagem usada para CPU

O kernel de exemplo vector_add recebe TileTensor e executa result[i] = a[i] + b[i] com base em 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]

Interoperabilidade com Python
- O Mojo é interoperável com Python de forma nativa, permitindo eliminar gargalos de desempenho sem reescrever todo o código existente
- É possível começar por uma única função e, conforme necessário, expandir movendo para Mojo o código sensível a desempenho
- Código Mojo pode ser importado naturalmente no Python e empacotado junto para distribuição
- Da mesma forma, bibliotecas do ecossistema Python também podem ser importadas dentro de código Mojo
- A função de exemplo mojo_square_array obtém um ponteiro de ctypes.data de PythonObject, calcula a largura SIMD em tempo de compilação e eleva ao quadrado os elementos do array
```
# 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)  
```

Metaprogramação em tempo de compilação

A metaprogramação do Mojo oferece um sistema intuitivo que usa a mesma linguagem do código de runtime para maximizar o desempenho
Com compilação condicional, permite criar otimizações específicas por hardware; com avaliação em tempo de compilação, garante segurança de memória e pode eliminar ramificações custosas em runtime
O objetivo é oferecer abstrações sem custo ao mesmo tempo em que expressa claramente a intenção

A implementação de exemplo de __eq__ usa reflexão em tempo de compilação para obter nomes e tipos dos campos da struct, verificar se todos os campos satisfazem Equatable e então realizar a comparação de igualdade campo a campo

# 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

Roadmap e open source

O Mojo começou no fim de 2022 e ainda há muito trabalho a ser feito
Phase 0
- Etapa de construção da base inicial
- Fase de implementação do parser principal, tipos de memória, funções, structs, inicializadores, convenções de argumentos e outros fundamentos da linguagem
Phase 1
- Etapa atualmente em andamento
- O objetivo é torná-la uma linguagem poderosa e expressiva para escrever kernels de alto desempenho em CPU, GPU e ASIC, além de permitir que desenvolvedores estendam Python de forma fluida
Phase 2
- Etapa de programação de aplicações de sistema
- Fase de expansão para suportar um modelo de segurança de memória garantida e mais recursos de abstração esperados por desenvolvedores de programação de sistemas
Phase 3
- Etapa de programação orientada a objetos dinâmica
- Fase de ampliar o suporte a recursos dinâmicos do Python, como classes, herança e variáveis sem tipo, para maximizar a compatibilidade com código Python
- Mais detalhes podem ser vistos no Mojo roadmap
- A biblioteca padrão do Mojo está totalmente open source no GitHub e aceita contribuições
- O compilador do Mojo tem abertura do código planejada para 2026
- Embora a diretriz seja tornar todo o Mojo open source, a equipe considera que, por a linguagem ainda ser muito jovem, um grupo próximo de engenheiros com visão comum consegue avançar mais rápido do que um modelo conduzido pela comunidade
- Como forma de participação, está disponível a developer community

Materiais de aprendizado e comunidade

Install e Quickstart guide: materiais para começar com Mojo
Beginner tutorial: aprendizado de Mojo criando o Game of Life
GPU puzzles: aprendizado de programação para GPU com Mojo resolvendo puzzles
Intro to Mojo: visão geral dos recursos da linguagem Mojo
Developer forum: perguntas e atualizações sobre Mojo
Events: informações sobre eventos, meetups, apresentações e hackathons
Contributions: orientações sobre issues abertas, contribuições de documentação e compartilhamento de projetos

1 comentários

GN⁺ 7 시간 전

Comentários no Hacker News

Nos últimos 2 anos usei bastante Mojo por diversão, e é realmente uma linguagem incrível
Tem um modelo de ownership próximo do Rust, execução em tempo de compilação mais poderosa que a do Zig, sistema de tipos rico e suporte SIMD de primeira classe
Em termos de desempenho, faz tempo que eu não via uma linguagem que não parecesse apenas um wrapper simples de LLVM. Ela ainda usa LLVM, mas de uma forma diferente de Rust ou Zig
Estou muito animado com o Mojo quando ele virar open source no fim deste ano
- Seria legal explicar um pouco melhor essa parte de “execução em tempo de compilação mais poderosa que a do Zig”
  Só pela documentação atual do Mojo, é difícil chegar a essa conclusão
Como alguém que trabalha com machine learning e se importa com desempenho, torço para que Mojo dê certo. Em especial, gosto da ideia de poder misturar código de GPU e CPU na mesma linguagem
Mas me preocupa que as mudanças atuais acabem afastando desenvolvedores Python. Da última vez que testei, fui tentar uma manipulação básica de string com var x = 'hello'; print(x[3]) e não funcionou, e len(x) também não, então perdi uma hora nisso
Aí descobri que decidiram separar com mais precisão as representações de bytes e code points, mas a documentação contradizia a implementação real
Espero que chegue a um ponto em que dê para usar em machine learning de forma geral, mas por enquanto ainda parece bem limitado. Algumas funcionalidades básicas legais ligadas a tensores também foram descartadas
Por enquanto vou continuar usando JAX e olhar de vez em quando
- Não entendo por que ainda não existe uma linguagem que transforme código simples focado em cálculo em SIMD / multithreading / multiprocessing / código de GPU com o mínimo possível de sintaxe extra
  Parece exatamente o tipo de coisa com que quem se interessa por compiladores e design de linguagem sonharia em fazer
  Não precisa garantir eficiência em toda situação nem entregar desempenho de ponta, seria bom só existir
  Pelo que entendo, daria para fazer uma linguagem assim, mas parece que não conseguiu despertar o interesse de quem seria capaz de criá-la
- Mojo é legal, mas não entendo por que continuam insistindo em compatibilidade com Python. Isso está atrapalhando a própria linguagem
  Quase todos os problemas que me vêm à cabeça com Kotlin são consequência da compatibilidade com Java. Aqui até poderia ter sido resolvido de uma forma mais explícita, mas o caminho atual parece condenado ao fracasso
- Se não for open source, não tem muito sentido. A maioria dos desenvolvedores Python não vai aparecer de qualquer forma
- Nesse aspecto, parece quase uma tentativa de recriar a linguagem de programação Nim
Está escrito que “prometeram disponibilizar o Mojo como open source no outono de 2026”
https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced
- Seria bom poder ver o código-fonte de um programa MLIR de ponta de verdade
Infelizmente, nesse meio-tempo a Nvidia também não ficou parada e criou uma CUDA de nova geração chamada CuTile para Python, e em breve para C++, por meio de uma stack de compilação semelhante baseada em MLIR
Mesmo sem portabilidade, há uma boa chance de ela ser muito mais usada que Mojo simplesmente porque a Nvidia vai promovê-la com força, integrá-la às ferramentas de desenvolvimento e fazê-la funcionar junto com código CUDA já existente
É bem possível que o Tile IR tenha surgido mais como resposta à ameaça do Triton do que do Mojo. Acho isso especialmente verdadeiro do ponto de vista de quão fácil é escrever kernels de LLM com desempenho razoável
- Para não ficar para trás, Intel e AMD também estão fazendo esforços parecidos, e o JIT do CPython finalmente está se tornando realidade depois de várias tentativas
  Também existem iniciativas como GraalPy e PyPy
  Todos esses esforços funcionam no Windows hoje, o que importa bastante em empresas onde a maioria dos funcionários recebe máquinas Windows e só os servidores usam distribuições Linux
  Isso me faz pensar se não vai acabar como mais um Swift for Tensorflow
- Pelo que conversei com alguns desenvolvedores de Tile IR, a principal motivação era oferecer melhor portabilidade para programação de tensor cores do que o PTX
  Fora feedback de clientes, ninguém disse que era uma resposta a alguma outra coisa
- Muita gente confunde Mojo com algo como apenas uma sintaxe boa para escrever código de GPU, e acha que o framework Python da Nvidia já cumpre esse papel
  Mas o CuTile vai rodar em GPUs AMD ou no Apple Silicon? Não importa o que a Nvidia faça, a dependência de fornecedor continua existindo
- Fico curioso sobre o tamanho real da influência do CuTile
Quando ouvi falar de Mojo pela primeira vez, achei que ele seria feito para ser compatível com código Python existente
Mas no futuro próximo isso parece estar muito longe do objetivo. Dá para chamar código indo e voltando entre Python e Mojo, mas o próprio Mojo não consegue executar código Python existente
- Na divulgação inicial, isso claramente era um dos pontos centrais. A ideia era que você adicionaria type hints ao código Python e teria um grande ganho de velocidade
  Mas parece que a direção mudou conforme o desenvolvimento avançou
- Se eu me lembro bem, chegaram a divulgar até 36.000 vezes mais rápido que Python equivalente, sem deixar nada claro que isso só era possível em casos extremos
  Parece mais um esquema de criptomoeda estilo pump and dump do que uma tentativa honesta de melhorar o ecossistema Python
- Se você observasse com bastante cuidado, desde o começo ficava claro que a ideia era criar uma linguagem de sistemas de próxima geração
  Ela pegava lições de Swift e Rust, mirava CPU/GPU/alvos heterogêneos e colocava MLIR no centro da linguagem
  Ao mesmo tempo, a arquitetura parecia pensada para um dia tornar relativamente fácil embutir ou estender Python, e esse enquadramento em torno de Python quase certamente ajudou na captação de recursos
  Chris Lattner falou muito mais sobre a relação entre MLIR e Mojo do que sobre a relação entre Python e Mojo
- Era assim que vendiam originalmente. Queriam ser algo como o Kotlin do Python, mas mudaram de direção rapidamente
  Por isso, e por causa do modelo de desenvolvimento que não é totalmente open source, sempre pareceu um vaporware para mim
- No site está assim
  Interoperabilidade com Python: “Mojo interoperates natively with Python, enabling you to eliminate performance bottlenecks in existing code without rewriting everything. Start with a single function and incrementally port performance-critical code to Mojo as needed. Mojo code imports naturally into Python and packages alongside for deployment. Likewise, libraries from the Python ecosystem can be imported into Mojo code”
Mojo parece bom, mas hoje estou bastante satisfeito com Julia nesse espaço de computação numérica de alto desempenho envolvendo CPU e GPU
Tirando a parte de ter sintaxe parecida com Python, parece que esse nicho já foi praticamente resolvido. Até no próprio Python já existem ferramentas eficazes para tipos de problema menos complexos e mais isolados, como Numba e Triton
Para o mesmo objetivo, Julia é mais madura, e desde o ano passado a Nvidia vem equiparando as capacidades das ferramentas Python e C++ em CUDA
Com o compilador JIT Python do cuTile, dá para escrever kernels CUDA quase como em Python puro
AMD e Intel também estão seguindo uma abordagem parecida
Ainda resta ver se o Mojo vai chegar a tempo de conseguir adoção mais ampla
- Não está certo dizer que o compilador JIT Python do cuTile permite escrever kernels CUDA em Python puro. Não é Python puro hoje e nunca poderá ser
  Esses dialetos de Python “amigáveis a desempenho”, como Triton, Pythran, CuTile, Numba, Pycell, cuPy etc., parecem Python por fora, mas basta arranhar a superfície para ver que não são Python de forma alguma
  São DSLs com cara de Python feitas para facilitar otimização e inferência de tipos. Na prática, é exatamente assim que parecem. Em cada uma delas, muitas — talvez a maioria — das funcionalidades de Python não podem ser usadas, e ainda assim você continua preso aos problemas característicos do Python
  Sinceramente, Python é intrinsecamente ruim para eficiência e desempenho
  Isso vai muito além do GIL. Tipagem dinâmica, semântica por referência, monkey patching, modelo de objetos extremamente dinâmico, ABI do CPython, BigInt por padrão, sistema de módulos em runtime etc. fazem sentido para uma linguagem pequena de scripting, mas são muito ruins para computação de alto desempenho e eficiência
  O próprio ecossistema NumPy/SciPy é quase um conjunto de hacks para driblar as limitações do Python em aritmética de tensores simples limitada por CPU
  O desempenho básico do Python é tão ruim que até um loop for simples faz o Excel parecer um cavalo de corrida
  Mojo é diferente
  Em vez de hackear uma base problemática já existente, Mojo tenta começar de um ponto de partida limpo
  E, em vez de herdar mais de 30 anos de Python, tenta oferecer uma “experiência parecida com Python” sobre uma linguagem bem projetada com base na experiência acumulada em design de linguagens
  Só por isso eu já torço para que dê certo
Hoje em dia parece que, pelo menos para parte das pessoas, é preciso fazer propaganda destacando AI native logo de cara
Mas isso me causa certa rejeição. Parece uma expressão que na prática não quer dizer nada
Alguém entusiasmado com IA poderia explicar por que “por ser uma linguagem compilada e estaticamente tipada, ela também é ideal para programação orientada a agentes” faria sentido, e o que isso quer dizer?
- Depois que IA virou destaque, foi muito interessante ver o desespero estampado nas páginas iniciais desses produtos e serviços
  Para mim, o caso mais engraçado foi abrir a página do IBM DB2 e ver aquilo descrito como um banco de dados de IA
  Acho que a ideia é que, se você pega mais erros em tempo de compilação, um agente consegue verificar rapidamente o próprio trabalho de forma estática, sem depender de testes unitários ou outros testes
- Os LLMs atuais foram treinados em bibliotecas enormes de código do passado. Por isso, no futuro próximo eles vão funcionar melhor em linguagens já estabelecidas do que em linguagens novas
  Isso vale especialmente para linguagens como Python, que têm muito código open source disponível. Para novos entrantes, sem código existente para treinar, isso é um grande problema
  Então talvez esse marketing desesperado de AI native seja necessário para parecer relevante em um mundo “orientado a agentes”. O tempo dirá se é suficiente
- Não me considero um usuário fanático por IA, mas de fato uso
  Agentes tendem a se sair melhor quanto mais feedback recebem. Checagem de tipos é ótima para detectar automaticamente muitos erros bobos
  A questão é que, em geral, quanto mais pistas você der para o agente, melhor
- Não sei exatamente em que sentido a frase foi usada, e concordo que “AI native” em linguagens de programação assim parece meio sem sentido
  Sobre compilação e tipagem estática: ao fazer programação orientada a agentes, é muito útil conseguir detectar problemas em tempo de compilação
  Isso reduz os problemas encontrados em runtime e também os cenários que são mais difíceis para o agente resolver. Testes unitários podem cobrir parte dessa lacuna, mas não totalmente
  O que o site não diz é que Mojo provavelmente pode até ser uma escolha pior para programação orientada a agentes. Ainda não existe muito dado de treinamento de Mojo
- Isso é o novo “...on the blockchain”
  Python+ruff+pycheck e TypeScript compilam para bytecode, não para código de máquina. Também não têm tipagem estática no sentido de Rust
  Mesmo assim, já vi modelos gerarem código válido muito bom em ambos. Não precisavam ser estritamente “compilados” nem “estaticamente tipados”
  No fim, a IA só precisa de boas ferramentas para verificar código rapidamente e iterar, e não liga tanto para essas propriedades
A Modular pretende abrir o código de todo o SDK do Mojo, incluindo o compilador, até o fim deste ano
Está escrito que “o Mojo 1.0 será finalizado no fim deste ano, junto com a abertura do compilador e a oferta de estabilidade da linguagem”
https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-...
Continuo acompanhando o Mojo. Sinceramente, a coisa de que menos gosto no Python é a sintaxe
Alguém aqui mencionou Julia, e acho que é uma boa linguagem. Mas as mensagens de erro do compilador e a documentação das bibliotecas não estão no nível que eu esperaria de uma linguagem nesse grau de maturidade
Também me preocupam problemas de precisão em blogs que li no passado. Além disso, por causa do tamanho dos binários e do tempo até a primeira execução, não acho que eu conseguiria fazer com Julia o tipo de módulo Python que eu gostaria
Mesmo assim, espero que Mojo vire uma opção. Mas eu gosto de REPL e também da natureza dinâmica do Python, então no fim talvez eu nem saia do NumPy por questões de desempenho
- Para mim é o contrário. A única coisa de que gosto no Python é a sintaxe
  Por isso eu gosto tanto de Nim. Você ganha velocidade de nível C, execução em tempo de compilação, metaprogramação, sistema de tipos forte e segurança de memória, e o código ainda costuma ser curto e elegante
  Mojo também é interessante, mas até agora parece focar mais em machine learning do que em programação de uso geral. E, pelo que sei, o compilador ainda não é open source
- Gosto muito do design do Mojo. Ele não dá para comparar com Julia porque tem gerenciamento de memória determinístico
  Também parece que o Mojo está mais focado em virar uma linguagem robusta para uso industrial. Fiquei chocado ao ver que a primeira implementação de pré-compilação do Julia não oferecia entrada e saída de arquivos

Mojo 1.0 beta

Versões e materiais para começar

GPU e interoperabilidade com Python

Programação para GPU

Interoperabilidade com Python

Metaprogramação em tempo de compilação

Roadmap e open source

Phase 0

Phase 1

Phase 2

Phase 3

Materiais de aprendizado e comunidade

Leituras relacionadas

1 comentários

Comentários no Hacker News