4

Pitch: Estou criando uma linguagem de programação porque queria misturar a simplicidade do Go com controle de baixo nível

Fala, pessoal.
Há um tempo eu comecei a criar uma linguagem de programação chamada Glide.
Não comecei porque achei que o mundo precisava de “mais uma linguagem”. Comecei porque eu queria experimentar uma pergunta que sempre me incomodou:

e se desse para ter uma linguagem de sistemas com a praticidade de Go, mas com mais controle sobre memória, erros e
runtime?

Eu gosto da ideia de escrever código direto, previsível e nativo. Mas muitas vezes as opções acabam caindo em extremos:

  • C te dá controle, mas cobra caro em segurança e ergonomia.
  • Rust te dá segurança forte, mas nem sempre é simples de explicar, aprender ou prototipar.
  • Go é muito produtivo, mas esconde bastante coisa do runtime e não foi feita para controle de baixo nível.

O Glide nasceu nesse espaço intermediário.
A proposta dela é ser uma linguagem pequena, compilada para código nativo, com:

  • erros como valores;
  • memória com ownership simples e auto-drop por escopo;
  • borrows sem anotações de lifetime;
  • concorrência M:N com spawn e canais tipados;
  • macros e procedural macros;
  • HTTP, JSON, TLS, WebSocket e tooling já na stdlib;
  • compilador escrito em Glide.

Um exemplo de erro como valor:

fn parse(n: int) -> !int {
if n < 0 { return err("negative"); }
return ok(n * 2);
}

fn pipeline(n: int) -> !int {
let v: int = parse(n)?;
return ok(v + 1);
}

!T é um resultado. ?T é uma option. Não existe try/catch. O erro aparece no tipo da função.

A parte de concorrência segue uma ideia mais próxima de Go:

fn worker(c: chan) {
c.send(42);
}

fn main() -> int {
let c: chan = make_chan(1);
spawn worker(c);
return c.recv();
}

Mas por baixo existe um scheduler M:N próprio, canais tipados e runtime nativo.

Outra coisa que eu queria evitar era fazer uma linguagem que só tivesse “hello world”. Então fui colocando tooling e stdlib desde cedo. Hoje o Glide já tem package manager, test runner, benchmark runner, LSP, formatter, geração de docs, tree-sitter, extensão para VS Code/Zed e uma stack HTTP.

Por exemplo, dá para escrever uma API REST com JSON tipado assim:

@derive(JsonBind)
pub struct Todo {
pub id: string,
pub title: string,
pub done: bool,
}

@handler
fn create_todo(body: Json) -> Json {
let in: CreateTodo = body.val;
let t: Todo = Todo { id: in.id, title: in.title, done: false };
store().insert(t.id, t);
return Json::wrap(t);
}

O Glide ainda é nova. A versão atual é 0.1.1. Não estou vendendo como “pronta para substituir X em produção”. O que eu queria compartilhar é o experimento: uma tentativa de criar uma linguagem de sistemas com menos cerimônia, bom tooling e runtime próprio.

O compilador já é self-hosted: existe uma seed em C para bootstrap, mas depois o Glide compila para Glide.

Repo: https://github.com/glide-lang/Glide

Carregando publicação patrocinada...
3

Ironicamente Go se classifica como uma linguagem de sistemas. Mas vai ver que é só como ela se sente, né? Isso que é importante, não o que é</ironia>

Eu sempre aprecio e incentivo pessoas a saírem da casinha e criar algo que não seja um produto pra ganhar dinheiro.

Poderia me explicar mais sobre ownership e borrow sem lifetime explícita na Glide? Como funciona? Tem limitações? Por que Glide consegue fazer algo que Rust não consegue? Imagino que isso vale para arenas também?

O que acontece se retornar um err()?

Fora as corrotinas, me parece que está criando algo mais próximo de Rust, não Go.

Antes de finalizar, conhece Zig? Odin? Ou outras linguagens que têm ser uma better C? Uma destas pode servir de inspiração ou mesmo perceber que já existe o que deseja criar (o que não torna o projeto sem sentido, porque ele pode ter outro objetivo que não o de ser melhor que C). Não Rust não é essa linguagem.

S2


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).

2

Sobre Go como linguagem de sistemas: eu entendo a crítica. Quando falo desse espaço, penso mais em controle,
previsibilidade, binário nativo, baixo overhead e capacidade de escrever tooling, runtime, servidores e partes mais
próximas da infraestrutura. Go entra em parte disso, mas realmente não tenta ocupar o mesmo lugar que C, Zig ou Rust.

Sobre ownership/borrow no Glide: a ideia não é copiar o Rust nem dizer que o Glide “faz o que Rust não consegue”. Rust
resolve um problema muito difícil: segurança de memória sem GC, com controle fino e garantias fortes em tempo de
compilação. O custo disso é um modelo de ownership/borrow mais explícito, incluindo lifetimes quando a inferência não
basta.

No Glide, o caminho é diferente. A linguagem usa arenas como modelo principal de memória, então muitos valores vivem
dentro de um escopo/arena e são liberados em bloco. Isso reduz bastante a necessidade de rastrear ownership fino objeto
por objeto. Em vez de provar todas as relações de tempo de vida como o Rust, o Glide tenta tornar o caso comum mais
simples: alocar, usar dentro de um escopo claro e descartar tudo junto.

Isso tem limitações. Não é a mesma garantia formal do borrow checker do Rust. Se você quer controle máximo e garantias
muito fortes contra dangling references em todo cenário possível, Rust continua sendo a referência. O Glide tenta trocar
parte dessa rigidez por ergonomia e previsibilidade, usando arenas, escopos e convenções mais simples.

Sobre err(): funções que podem falhar retornam um tipo de resultado, como !T. Então um err(...) não é exceção; é um valor
de erro. Quem chama precisa lidar com isso ou propagar usando ?. A ideia é deixar o fluxo de erro explícito, mais
parecido com Result do Rust/Zig do que com exceções.

E sim, eu conheço Zig, Odin e outras linguagens nessa linha “better C”. Elas são referências importantes. Zig é muito
forte em controle explícito, comptime e integração com C. Odin tem uma pegada muito interessante para programação
prática, tooling e jogos/sistemas. Rust joga outro jogo: garantias fortes de segurança e concorrência, mas com uma
complexidade maior.

Eu diria que o Glide está mais próximo dessa família de linguagens compiladas modernas do que de Go puro. Ele tem algumas
ideias que lembram Rust/Zig/Odin, mas com outro equilíbrio: arena allocation por padrão, erros como valores, corrotinas
M:N, canais, traits e uma sintaxe que tenta continuar simples.

Então a proposta não é “fazer o que Rust não consegue”, nem fingir que Zig/Odin não existem. É explorar outro ponto no
mapa: uma linguagem generalista, grande, com controle razoável, ergonomia boa e escolhas próprias de memória, erro e
concorrência.

1

Você parece estar fazendo um bom trabalho, ou pelo menos ele está bem adiantado. Não é projeto de uma pessoa emocionada que está tentando fazer alguma coisa qualquer, o que eu valorizo também, mas uma iniciativa mais estruturada é bem mais interessante.

Eu conheço bem o funcionamento de arenas, e sei que tem um certo problema para garantir que tudo não escape de uma arena, isso não é tão simples, precisa ter um mecanismo que garanta isso ou terá o problema que tem em C, por exemplo. O risco é menor, mas entendi que você preferiu deixar acontecer se o programador não se atentar o escape.

Eu entendi como o sistema de result funciona, o que faltou foi um exemplo de tratamento do err() diferente da propagação. Eu até imagino como seja, mas pode ser que você criou algo diferente.

Conhece Jai? Até onde dá para conhecer. Estou acompanhando lá e o GH.

Agora pude ver mais informações que você resolveu o problema com o website da linguagem.

Quero ver de perto como está a implmentação da concorrência que é algo que eu nunca me aprofundei tanto.

1

Projeto massa.

Estou criando uma linguagem também, a base da minha é Pyhton e C.

Criou os booleanos -T e -F? Eu fiz assim na minha.

Estou achando que com a IA, os programadores irão conseguir converter um projeto para suas ferramentas. Assim, só teríamos que se preocupar com a lógica e aplicabilidade coesa no futuro.

0

Valeu!

No Glide eu mantive booleanos mais convencionais, tipo true e false, em vez de -T e -F. Achei melhor seguir algo mais
familiar para reduzir atrito de leitura, principalmente pensando em projetos maiores e em gente vindo de outras
linguagens.

Sobre IA, concordo em parte. Acho que ela vai facilitar muito portar código, gerar bindings, migrar APIs e adaptar
projetos entre ferramentas. Mas ainda acho que a linguagem importa bastante, porque ela define o modelo mental: como você
trata erro, memória, concorrência, modularização, testes e manutenção.

Então talvez a IA reduza o custo de conversão, mas não elimine a importância de uma linguagem ter uma proposta coesa. No
fim, a lógica continua sendo o centro, mas as ferramentas moldam bastante como essa lógica fica sustentável ao longo do
tempo.

1
2

Pensei a mesma coisa. Parece que bastante coisa já foi feita no Glide, entao eventualmente será diferente aqui e ali, mas a ideia é essencialmente a mesma. De qualquer forma, gosto do V, então provavelmente vou gostar do Glide também.

1

Faz sentido a associação. V é uma referência natural quando alguém vê uma linguagem compilada, simples, com foco em
produtividade e binário nativo.

Eu diria que existe uma interseção de objetivos, mas não que a ideia seja essencialmente a mesma. O Glide quer ser uma
linguagem generalista e grande, com ecossistema próprio, mas algumas escolhas de base seguem outro caminho: erros como
valores (!T), arena allocation por padrão, corrotinas M:N, canais, traits/dyn dispatch e uma stdlib desenhada com essas
decisões desde o começo.

Então talvez de fora pareça a mesma categoria, e tudo bem. A diferença real vai aparecer mais nas decisões de semântica,
runtime, memória, concorrência e ergonomia conforme a linguagem amadurecer.

E se você gosta do V, provavelmente algumas coisas do Glide vão parecer familiares mesmo. Só não quero vender como “V com
outro nome”, porque a direção técnica não é essa.

1

Não é a mesma ideia do V, embora existam semelhanças superficiais: sintaxe simples, compilação nativa e foco em
produtividade.

A proposta do Glide é ser uma linguagem grande, prática e completa, não só um experimento pequeno. A ideia é ter uma
linguagem capaz de cobrir backend, ferramentas de sistema, CLIs, aplicações concorrentes e projetos maiores, mas com
alguns diferenciais fortes desde a base: erros como valores, arena allocation por padrão, concorrência com corrotinas M:N
e canais, traits/dyn dispatch e uma stdlib pensada para ser coerente.

Então a comparação com V faz sentido como referência inicial, mas o Glide não quer ser “um V alternativo”. A ambição é
construir uma linguagem generalista, com ecossistema próprio, usando algumas escolhas de design diferentes para tentar
entregar uma experiência mais previsível e produtiva.

1

Projeto animal! É muito difícil achar esse equilíbrio entre a simplicidade do Go e o controle real de memória do baixo nível sem virar um "monstro" de complexidade