- Chris Lattner é um dos principais desenvolvedores do LLVM e da linguagem Swift, e está desenvolvendo a nova linguagem Mojo para aproveitar ao máximo o desempenho do hardware moderno de ML
- Mojo tem como objetivo um design de linguagem que ofereça tanto usabilidade quanto controle detalhado do hardware, com suporte ao uso de metaprogramação com segurança de tipos para lidar de forma eficiente com os detalhes do hardware
- O contexto central é resolver o problema de fragmentação do ecossistema de aceleradores de IA — como GPU, TPU e ASIC — e construir uma plataforma de computação unificada para reduzir a dependência de fornecedores específicos
- Devido aos problemas de compatibilidade e complexidade das stacks de software de GPU existentes (CUDA, ROCm, XLA etc.), tornou-se essencial desenvolver uma linguagem de próxima geração com alto desempenho e portabilidade
- A Modular está seguindo um modelo de negócios focado em resolver problemas reais, oferecendo o Mojo gratuitamente e concentrando-se em suporte unificado a hardware e serviços corporativos
Apresentação de Chris Lattner e sua carreira
- Chris Lattner liderou vários projetos centrais da computação, como LLVM, Clang, MLIR, Swift e Mojo
- Trabalhou em organizações como Apple, Tesla, Google, SiFive e Modular, acumulando ampla experiência prática em compiladores e design de linguagens de programação
- No início, partiu de linguagens simples como BASIC e do ambiente de PCs, e passou a se interessar por extrair o máximo desempenho do hardware por meio de jogos e gráficos
- Na universidade, acabou sendo influenciado por um professor especializado em compiladores e descobriu o fascínio por sistemas e pela estrutura de software em larga escala
Entre compiladores e design de linguagens
- Chris Lattner acumulou experiência tanto em engenharia de compiladores quanto em design de linguagens, obtendo grandes resultados na interseção entre essas duas áreas
- Por exemplo, o LLVM é uma linguagem intermediária que pode ser usada por várias linguagens, e gerou ampla adoção em implementações que vão além de C++, como Rust e Julia
- O desenvolvimento do Swift também começou como uma tentativa de superar as limitações e o desgaste da implementação existente em C++, valorizando a necessidade de recursos práticos como pattern matching
- Na inovação em linguagens de programação, ele prefere uma abordagem baseada em resolver problemas reais e utilidade prática, mais do que em teoria matemática
Teoria de linguagens de programação e pragmatismo
- Chris busca um raciocínio voltado à resolução de problemas mais do que ao rigor matemático, e em artigos de PL se interessa mais por exemplos práticos e casos de uso do que pela teoria em si
- Ele reconhece que recursos de linguagem com base matemática forte têm vantagens em consistência e composabilidade, mas a adoção no mundo real é impulsionada por utilidade visível no uso
- Ele menciona que, em novas linguagens ou tecnologias, é importante reduzir ao máximo o "grão de areia (grain of sand)" da complexidade, buscando simplicidade e escalabilidade no design
Problemas estruturais do ecossistema de hardware de IA
- A infraestrutura tradicional de compiladores (LLVM) era centrada em CPU, mas IA/machine learning exige diversos tipos de hardware especializado, como GPU, TPU, ASIC e FPGA
- Cada fornecedor desenvolve sua própria stack de software (CUDA, ROCm, XLA etc.), o que leva à falta de compatibilidade e à fragmentação do ecossistema
- Softwares de ML (como PyTorch) exigem otimizações separadas para cada fornecedor de hardware, tornando manutenção e expansão muito difíceis
- Como cada hardware tem stack, linguagem e ecossistema de ferramentas diferentes, há perda generalizada de produtividade e portabilidade para desenvolvedores de software
O papel da Modular e do Mojo
- A equipe da Modular está focada em construir uma plataforma de software genérica e unificada para resolver esses problemas
- O Mojo foi projetado com o objetivo de permitir tanto especialização de desempenho para arquiteturas modernas de GPU (como tensor cores) quanto a escrita de kernels portáveis para diferentes hardwares
- Com uma estrutura em várias camadas que inclui Mojo, MAX (como serving de LLM de alto desempenho) e Mammoth (gerenciamento de cluster/Kubernetes), a empresa busca oferecer uma infraestrutura de IA integrada
Contexto da necessidade do Mojo e decisões de design da linguagem
- Com as linguagens existentes, não é possível atender ao mesmo tempo às duas exigências de portabilidade de kernels de ML de alto desempenho e otimização específica por fornecedor
- O Mojo precisa ser capaz de responder de forma dinâmica a hardwares em rápida evolução, incluindo detalhes da arquitetura, como diferentes tipos de dados (por exemplo, floating point de 8 bits) e tensor cores
- Com um modelo de metaprogramação com segurança de tipos, ele transforma o controle complexo de hardware em uma forma mais eficiente e compartilhável
Mudanças no hardware e no design de kernels
- As CPUs dos datacenters modernos escalaram para muitos núcleos, enquanto as GPUs evoluíram rapidamente com arquiteturas voltadas a processamento paralelo, como a estrutura de SM (Streaming Multiprocessor) e Warps (execução de 32 threads)
- Com a introdução em hardware de unidades de computação dedicadas à IA, como tensor cores, tornou-se necessário um paradigma de programação de hardware completamente diferente do CUDA tradicional
- Até dentro do mesmo fornecedor, mudanças de compatibilidade entre gerações de arquitetura se tornaram frequentes (por exemplo, entre Nvidia Volta/Hopper/Blackwell), e a stack de software não consegue acompanhá-las
Modelo de negócios e estratégia de ecossistema aberto
- A Modular não está focada em vender a linguagem em si, e disponibiliza o Mojo gratuitamente
- Seu principal modelo de receita se baseia em plataformas/serviços voltados ao gerenciamento unificado de hardware e ao mercado corporativo
- Com isso, tenta construir um ecossistema comum sem vendor lock-in, buscando ao mesmo tempo suporte a diferentes hardwares e gestão eficiente de infraestrutura
Conclusão
- O projeto Mojo, de Chris Lattner e da Modular, representa a construção de uma nova linguagem de programação e plataforma para lidar com o avanço do machine learning, a inovação em hardware de IA e a superação da fragmentação do ecossistema
- Por meio de um design de linguagem inovador e da expansão de um ecossistema aberto, a estratégia busca contribuir para a democratização do ecossistema de IA e para o aumento da produtividade
1 comentários
Opiniões no Hacker News
Quero agradecer a todos pelo interesse no Mojo e no podcast. Se quiser saber mais sobre o Mojo, dá para ver as perguntas frequentes no FAQ (incluindo a resposta para “por que não tornar Julia melhor?”). A documentação também pode ser consultada aqui, e o código open source já foi publicado com centenas de milhares de linhas. A comunidade do Mojo também é realmente excelente, então seria ótimo se vocês participassem do fórum no Discourse ou do chat no Discord - comentário de Chris Lattner
Sou fã. Assisti a várias apresentações sobre o Mojo e, embora digam que ele usa tecnologia de compiladores de ponta, nunca ouvi exemplos concretos. Mesmo sem ser desenvolvedor de compiladores, eu gostaria de sentir um pouco do que essa tecnologia avançada realmente oferece, nem que eu entendesse só uns 20%, então seria ótimo ver um post de blog realmente profundo e técnico
No FAQ, a pergunta "O Mojo Playground ainda está disponível?" direciona para esse playground, mas lá mesmo aparece o aviso de que “o Playground será removido na próxima release 25.6”. Parece que a resposta do FAQ sobre “isso está disponível?” acabou apontando para uma funcionalidade prestes a ser removida, o que perde um pouco o ponto central. Na prática, a resposta parece ser “não por muito tempo”
Chris, é bom te ver por aqui. No passado eu até investi por meio do Light Table e queria saber se há alguma atualização. (Não estou perguntando seriamente, e o Mojo realmente parece legal.) Fico curioso sobre a sustentabilidade de longo prazo desse tipo de projeto e se existe alguma base confiável para acreditar nisso
O Python domina a área de ML porque aplicações modernas de ML não são scripts simples de cálculo, mas exigem uma ampla gama de funcionalidades e um ecossistema robusto. Pré-processamento de dados de todos os tipos (ETL), manipulação de dados em vários formatos, processamento distribuído em clusters de computação de alto desempenho, visualização e integração com GUI/BD — não há outra linguagem além de Python que cubra tudo isso. As operações numéricas são muito rápidas porque NumPy, PyTorch, JAX etc. usam C/C++/FORTRAN internamente, e também é fácil implementar separadamente em C/C++ apenas o código crítico para desempenho. O sistema de FFI em C/C++ do Python também é suficientemente prático em comparação com outras linguagens. Isso traz muito mais vantagens do que reimplementar todo o ecossistema em outra linguagem, como Julia
O ecossistema do Python é incomparável, mas a combinação Elixir/Nx já faz boa parte do que o Mojo promete. Via EXLA, também dá para compilar para GPU/TPU; com Explorer/Polars, fazer trabalho com dataframes; e com Pythonx, embutir bibliotecas Python. A diferença é que o Elixir foi pensado desde o começo para construir sistemas distribuídos, então BEAM/OTP também consegue lidar com um grande volume de requisições concorrentes e coordenar entre nós com GPU. Se você estiver construindo um serviço real de ML, talvez seja mais importante ter uma stack sólida com Phoenix, LiveView e Nx, obtendo tolerância extrema a falhas e escalabilidade, do que ganhar um pouco de desempenho de hardware
Tenho uma visão um pouco diferente do lado de inferência. É fácil mexer diretamente em kernels CUDA, e o CUTLASS 3 mais recente ou o C++ moderno ficaram bem mais convenientes. O Torch fica como uma camada fina por cima, mas essa parte é difícil de compilar e só adiciona complexidade por vários motivos, inclusive contagem de referências. A implementação realmente essencial está nos kernels de baixo nível e, em breve, penso em remover essa “cobertura do torch” e conectar tudo de forma clara em um programa limpo em C++
Esse problema é uma preocupação com kernels de GPU, mas esses kernels já não são escritos em Python de qualquer forma. Python é a linguagem de “cola” para ML. Concordo com a afirmação de que “só Python oferece tudo”, mas também é um pouco lamentável que o ecossistema tenha crescido em torno do Python e não de uma linguagem melhor
O fato de Python ter virado a principal linguagem de ML é um “círculo virtuoso”. O ecossistema só cresceu porque ele já tinha sido escolhido; é preciso uma explicação separada para o motivo da escolha inicial. Hoje ele ficou tão grande que parece impossível de superar, mas isso não basta como argumento para explicar por que Python foi escolhido desde o começo
Ironicamente, Python é a pior linguagem para todas as tarefas mencionadas. Empacotamento e binários (
wheel) são um sofrimento, e sempre tem alguma coisa quebrando. Para scripts isolados até serve, mas se Python tivesse sido projetado com o objetivo de virar a linguagem principal de ML, ninguém teria querido que ele fosse assimFiquei chocado ao ouvir o episódio. Foi surpreendente ouvir que, mesmo em setembro de 2025, suporte a classes ainda seria uma meta de médio prazo. Antes, o Mojo era muito divulgado como “superset de Python”, mas no ritmo atual isso parece mais um objetivo idealizado
Na verdade, nunca foi objetivo ser um “superset de Python”. Era mais um slogan para atrair a atenção das pessoas, algo enfatizado só no começo e depois discretamente abandonado
Talvez não seja uma questão de velocidade, mas de simplesmente não gostar de POO em si
Sempre foi um objetivo de longo prazo
Talvez seja uma pergunta meio comum, mas fico curioso sobre por que não Lisp. Assumindo que, no futuro, o código de ML acabe sendo escrito por máquinas (ou por sistemas automáticos de transformação baseados em linguagem natural), S-Expressions de Lisp são praticamente ASTs, então seriam a linguagem mais natural para máquinas. Como o ambiente REPL normalmente também é bem completo, parece que também se encaixaria muito bem como substituto de Python
Yann LeCun e outros chegaram a criar o Lush, um Lisp para ML. Era o melhor nos anos 2000, e não havia alternativa até surgirem Python (Theano) e Lua (Torch). Ainda hoje eu gostaria que Lisp voltasse a receber atenção. As bibliotecas do Python são excelentes, mas a linguagem em si ainda tem muitos pontos a melhorar
LLMs (grandes modelos de linguagem) ainda são fracos para contar parênteses ;)
Como já houve a experiência de Lisp ser deixado de lado no boom anterior de IA, muitos desenvolvedores ainda usam só Emacs + SBCL. Na prática, também existem outras implementações avançadas de Lisp, como LispWorks, Allegro e Clozure, mas muita gente nunca as experimentou
Não gosto nem da licença do Mojo
Eu também fui conferir, e a licença do Mojo diz que, para usos em CPU ou Nvidia e outros “aceleradores” (TPU, AMD etc.), se for uso comercial é necessária uma licença separada veja o blog
Do meu ponto de vista, se for uma linguagem controlada de forma absoluta por uma empresa específica (Mojo), não há motivo algum para adotá-la no meu negócio. Já houve muitos casos de empresas enfrentando problemas com mudanças de licença no Java. Colocar um negócio em cima de Mojo em vez de Python é arriscado demais
No FAQ do Mojo, parece que eles visam um superset de Python em sentido estrito, mas no roadmap dizem que “oferece código Python e familiaridade com Python, mas não pode ser um superset completo”, o que só aumenta a confusão. Se compatibilidade com Python não é o objetivo, não entendo por que continuam mencionando Python. Também fico curioso se essa história de usar emoji como extensão de arquivo é real
Pelo que eu sei, o Mojo busca apenas sintaxe no estilo de Python e interoperabilidade com Python. Qualquer afirmação de que ele seria mais parecido com Python do que isso tem um peso grande de marketing
Sobre a extensão com emoji, sim, é verdade. É o U+2615 (emoji de café)
Quero entender em que o Mojo é melhor que Julia. Julia também tem limitações de interface e ecossistema, mas se integra bem com Python, então não me parece que o Mojo seja claramente superior
Em especial, Julia tem um ecossistema de GPU bem estruturado, com JuliaGPU e Reactant veja Reactant.jl
A compatibilidade com Python talvez seja melhor no Mojo, mas na prática também é bastante estável chamar bibliotecas Python a partir de Julia com PythonCall.jl. Frameworks de ML (Lux.jl, Flux.jl) também funcionam bem dentro de Julia. O Mojo ainda não parece ter frameworks nativos de ML em nível semelhante
O Mojo parece buscar muito mais a sensação de linguagem de baixo nível, com mais controle e robustez. Julia, por outro lado, não é previsível em termos de significado ou desempenho, o que a torna inadequada como base de software crítico, enquanto o Mojo leva vantagem nesse ponto
Tentei criar módulos Python em Julia, mas senti que o suporte ainda é insuficiente. No Mojo, isso é uma funcionalidade central
Julia ainda não tem bom suporte para compilar código Julia em binários totalmente nativos (como Rust ou C++)
Tenho a impressão de que o fato de o Mojo não estar recebendo atenção enorme e de PyTorch continuar dominante pode ser um indício de que a questão da licença é, na prática, maior do que se esperava
Parece que o Mojo definiu seu espaço de atuação com otimismo demais. Julia também vem aumentando gradualmente seu uso comercial e tem bom suporte a GPU. Mesmo que o compilador JIT do Python seja fraco, Nvidia, Intel e outras empresas já otimizam bastante a programação GPGPU com DSLs em Python, então dá para usar Python de forma bem próxima ao nível de C++. No fim, o Mojo tem pouco diferencial
Do ponto de vista de sistemas, é impressionante a tentativa de Chris e da equipe de resolver de vez os problemas de FFI entre várias linguagens com o Mojo. Mas, até virar open source, não dá para começar nem a discutir investimento
Ainda não está pronto para uso como linguagem de programação geral. A própria Modular tentou aplicar a API do Mojo ao motor MAX, mas abandonou o investimento porque a linguagem mudava rápido demais. A adoção mais séria só deve acontecer depois da conclusão da fase 1 do roadmap
Não sei se isso está realmente público de verdade. Até recentemente, como ainda não havia sido open-sourced, eu hesitava em depender de software proprietário comercial
No começo do texto, dizem que é possível usar “kernels de ponta”. No fim das contas, parece que o Mojo quer competir com C++ no desenvolvimento de kernels. Em PyTorch ou Julia, normalmente você não escreve kernels diretamente, ficando mais no código de alto nível
Existem episódios do podcast do Lex Fridman com participação de Chris Lattner:
A tentativa com o Mojo em si é ousada e interessante, mas se for uma linguagem fechada como Matlab, isso é um impedimento sério para mim e para muita gente