- Unison é uma linguagem de programação funcional baseada em uma estrutura que identifica definições de código pelo conteúdo (Hash), e não pelo nome), reorganizando do zero toda a forma de armazenar, versionar e distribuir código
- Todo o código é armazenado em uma codebase (DB), e não em arquivos de texto; os nomes são tratados apenas como rótulos, fazendo com que problemas como conflitos de mesmo nome/arquivo e conflitos de refatoração desapareçam estruturalmente
- Por meio do UCM (Unison Codebase Manager), é possível adicionar, remover, mover, renomear, testar e executar definições, com um ecossistema de ferramentas colaborativas conectado a LSP, UCM Desktop e Unison Share
- Além de recursos da linguagem como sistema de efeitos baseado em Abilities, computação atrasada e pattern matching estrutural, ela se expande para um modelo integrado no qual a lógica da aplicação e a implantação em nuvem (Cloud/BYOC) são definidas juntas no mesmo programa
- Graças à estrutura baseada em hash, características como eliminação de compilação duplicada, redução de conflitos de versão e navegação estática por referências tornam-se propriedades nativas, oferecendo uma experiência consistente de desenvolvimento distribuído com sistemas de Share, Cloud, Projects e Branch
Visão geral da linguagem Unison
- As definições são gerenciadas com uma estrutura de identificação baseada em conteúdo (content-addressable code), então mesmo que tenham o mesmo nome, se o conteúdo for diferente elas são tratadas como definições totalmente distintas
- recompilação desnecessária, conflitos na evolução de API minimizados e estabilidade total de referências
- A codebase é mantida como um banco de dados baseado em SQLite, e código, nomes e documentação são armazenados como dados
- é possível explorar a estrutura com comandos do UCM como
ls e view
- Arquivos de texto são apenas uma interface de edição; a única fonte da verdade do código real é o DB
- conflito de nomes, conflitos de merge de arquivos e gestão de estrutura de repositório tornam-se conceitos reduzidos e ultrapassados
Recursos da linguagem
- Abilities: recurso para controlar efeitos como IO e Exception por meio do sistema de tipos
- Pattern matching estrutural: decompõe tipos estruturalmente para compor o fluxo de controle
- Computação atrasada (Delayed computations): expressa explicitamente avaliação não estrita
- Tipagem estática forte + inferência de tipos rica + suporte a Kind-checking
Ambiente de desenvolvimento e toolchain
- UCM (Unison Codebase Manager)
- criação, remoção, renomeação, testes e execução de definições
- incorpora à linguagem um controle de versão no estilo Git com projetos, branches, clones e merges
- UCM Desktop
- exploração da estrutura da codebase, navegação por definições via clique e renderização de documentação
- Suporte a LSP
- recursos de IDE disponíveis na maioria dos editores populares
- Unison Share
- hub central de código: hospedagem de projetos, busca, review, contribuições (=Pull Request) e pesquisa baseada em tipos
- como todas as definições são baseadas em hash, as referências sempre podem ser navegadas como hiperlinks
Modelo de implantação: Unison Cloud & BYOC
- Com a mesma linguagem, é possível escrever a lógica da aplicação + a definição da infraestrutura e implantar isso diretamente
- Construção de sistemas distribuídos apenas com “código”, sem YAML, Helm ou protocolos RPC complexos
- Com BYOC (Bring Your Own Cloud), também é possível executar a stack Cloud sobre sua própria infraestrutura de contêineres
- Inclui armazenamento com segurança de tipos, como OrderedTable, suporte a Daemon e orquestração automática
Exemplo: Guessing Game
- Exemplo simples de CLI usando Abilities (IO, Exception)
- Forma em que elementos da linguagem, como Random, console IO, pattern matching e computação atrasada, se combinam naturalmente
Ecossistema e comunidade
- Suporte a contribuições, review e contas de organização via Share
- Busca em todo o ecossistema baseada em tipos e fornecimento de servidor MCP para agentes de IA
- Trabalho em andamento para C FFI
- Expansão de recursos de produtividade colaborativa, como visualizador de diff no estilo Git e anotações de branch
Principais marcos históricos (resumo)
- 2018: fundação da Unison Computing
- 2019: primeiro lançamento alpha
- 2021: migração da codebase para SQLite (redução de 100x)
- 2021: lançamento público do Unison Share
- 2022~2024: LSP, Projects, Kind-checking, Pull Request, Cloud GA
- 2025: app Desktop, otimizações de runtime em larga escala, servidor MCP e suporte a BYOC
- nov. de 2025: lançamento oficial do Unison 1.0
FAQ
- Por que uma nova linguagem?
- o modelo de código baseado em hash é algo próximo do impossível de portar como addon para linguagens existentes
- como armazenamento de código, controle de versão, implantação e colaboração derivam naturalmente dessa ideia, foi necessário projetar uma nova linguagem desde o início
- Casos de uso reais?
- toda a Unison Cloud está escrita no próprio Unison e em operação
- há um fluxo de trabalho em nível comercial para colaboração entre organizações e equipes e desenvolvimento de aplicações distribuídas
- Preocupação com vendor lock-in: é uma linguagem open source, pode ser implantada livremente com Docker etc. e oferece suporte a BYOC
- Forma de colaboração: suporta organizações, tickets, code review, PR etc., e conflitos ocorrem apenas no nível das definições
- Controle de versão: oferece projetos, branches, push, pull e merge próprios, sem Git
- Sem restrição de IDE: fornece servidor LSP, permitindo o uso de vários editores
- Integração com outras linguagens: C FFI em desenvolvimento
- Acesso a codebase sem arquivos: a estrutura pode ser explorada com comandos de CLI (UCM) ou pelo app Desktop
1 comentários
Comentários no Hacker News
Acompanho Unison há muito tempo. Desde a época do blog pessoal do Paul, então já faz mais de 10 anos. Este lançamento 1.0 é realmente um grande marco, mas, sinceramente, fiquei um pouco decepcionado
Gosto muito de linguagens de programação e acompanhei o crescimento de linguagens como Rust, Go e Zig, mas sinto que o Unison, para esse nível de maturidade, tem pouca capacidade de expansão de ecossistema
Acho que isso se deve ao modelo de negócios, em que a maioria dos recursos foi projetada de forma dependente da nuvem. Existe uma opção de BYOC, mas não é suficiente. Tem algo aí que não encaixa bem
O projeto Share é open source, e o GitHub também tem dependências práticas e ainda assim continua popular.
Não estou tentando negar esses pontos, só queria que as pessoas experimentassem e percebessem o que pode ajudar em outros projetos de linguagem
Mas a maior parte do material de aprendizado parte do uso de infraestrutura em nuvem, então, em ambiente offline, a pessoa fica sem caminho.
Talvez exista uma abordagem no estilo Unison para isso, mas a camada de marketing está escondendo esse caminho
Quando surgirem usuários pagantes, haverá um incentivo para manter a tecnologia realista e prática.
Sem esse elemento comercial, teria parecido só mais uma esolang. Agora estou pensando em usar num projeto paralelo
A documentação menciona o Unison Share, e isso também é hospedado em unison-lang.org.
Existe a opção de BYOC, mas ainda assim é preciso conta e assinatura no unison.cloud. Gostaria que esse tipo de coisa fosse explicado com clareza no marketing e na documentação
Olá, sou um dos co-criadores da linguagem Unison. Se tiverem dúvidas, podem perguntar qualquer coisa
O Unison foi uma das primeiras linguagens a destacar algebraic effects (Abilities) como recurso principal.
Lembro que, no começo, não havia muita certeza se esse recurso seria bem recebido, então fiquei curioso para saber se vocês estão satisfeitos agora.
Queria ouvir também se o sistema de efeitos se integra bem com o restante da linguagem, se vocês gostam da sintaxe e se há histórias interessantes sobre a implementação interna
Documentação relacionada: Unison Abilities
Vocês guardam só o hash da expressão e um valor “passed”, ou também conseguem calcular o hash de todos os valores?
Se for a segunda opção, isso talvez permita ampliar builds reproduzíveis como no Nix ou Trustix.
Imagino que hoje o cache lide apenas com expressões vinculadas, mas talvez também possa servir como ponte para conectar o runtime ao mundo externo
Mas, no momento, ainda parece uma solução procurando um problema.
Queria entender para quem essa linguagem é feita e se existe algum uso real em produção além do Unison Cloud
No começo achei que fosse uma linguagem baseada em BEAM, mas ela roda em sua própria VM.
Gostaria de saber, em comparação com linguagens BEAM, quais são as diferenças em termos de fault tolerance e para quais casos de uso o Unison se encaixa melhor
Queria saber se elas chamam um banco de dados externo ou se são implementadas no próprio Unison.
Junto com a abstração Database, isso parece uma combinação muito interessante, mas não é fácil entender o conceito por completo
Considero o Unison uma das linguagens mais interessantes.
Acredito que algebraic effects serão um conceito central da próxima geração.
O Unison também tem várias outras ideias excelentes.
Pessoalmente, acho que ele pode servir bem até para desenvolvimento de mods de jogos.
É preciso executar código não confiável no cliente, e o sistema de abilities do Unison parece permitir criar um ambiente sandbox com facilidade.
Além disso, pode ser útil também para implementar ECS (Entity Component System).
Se for possível inferir as capacidades de que uma função precisa, então a segurança para execução paralela pode ser garantida automaticamente
No Cloud, não é possível usar a ability de IO diretamente; em vez disso, só são permitidas coisas como uma Http ability controlada com segurança.
Assim, o usuário não consegue acessar o sistema de arquivos.
Também estou pensando em aproveitar isso em desenvolvimento de jogos.
Outros usuários poderiam até implementar abilities como native service e contribuir para o jogo.
Links de referência: Unison Cloud, código validateSandboxed, exemplo de ECS
Quando vi este projeto pela primeira vez, pensei “como isso estará daqui a 5 anos”, e realmente esse tempo passou.
Estou muito feliz de ver agora o lançamento 1.0
É uma grande conquista ter tornado esse tipo de linguagem radical utilizável até em ambientes reais de indústria. Parabéns
Acho que sistemas como o Unison são o futuro da computação.
Mas não sei quando esse futuro vai chegar.
A beleza desse tipo de sistema está em reunir infraestrutura, dados e camada de serviços dentro de um único sistema integrado.
Talvez isso possa até servir como base melhor para agentes de código com IA.
Ainda assim, acho que combina mais com um modelo de desenvolvimento independente sustentável do que com o modelo de VC.
É muito admirável ver uma equipe continuar tocando um projeto tão de longo prazo
Lembro do dia em que o Rúnar disse que ia começar o Unison.
Achei que seria um projeto que abriria um paradigma totalmente novo, e agora, vendo o lançamento 1.0, fico realmente orgulhoso.
Espero que um dia o Unison se torne minha linguagem principal
Gostaria que o site do Unison tivesse benchmarks.
É preciso entender as características de desempenho para ter noção de para que ele serve melhor.
Seria bom ter nem que fosse números simples, como comparação de velocidade de processamento de requisições com Django, Express.js e ASP.NET.
As ideias são interessantes, mas espero que surjam também alvos de runtime além da web.
Pessoalmente, acho mais fácil experimentar uma linguagem nova em algo como ferramentas de CLI do que em grandes projetos web
Consultei este artigo de review do Unison, publicado em 2023, e achei bem útil
As ideias são interessantes, mas o Unison exige adotar de uma vez linguagem + gerenciamento de código-fonte + hospedagem numa estrutura all-in-one.
Se você não gostar nem de uma parte da stack, fica difícil usar o todo.
Por isso, acho que essas ideias terão dificuldade de se espalhar amplamente de forma direta
A qualidade das ferramentas da linguagem em si é muito alta, e também dá para integrar com sistemas existentes.
Por exemplo, o Unison Cloud foi escrito majoritariamente em Unison, mas algumas partes usam Haskell.
Discussões relacionadas: thread HN 1, thread HN 2
Acho que há muito valor em projetar várias tecnologias de forma orgânica para que funcionem bem juntas