1

Opa! Quem sabe! ksksk

Não, é algo mais original mesmo. Eu tenho mania de acordar no meio da noite com ideias, e começar a fazer. Neste caso, foi uma das raras boas ideias ksksks

Quando digo "mais baixo nível do que C", eu digo:

Carla é pensado para ser apenas um "wrapper" de assembly. Ser o mais próximo e direto possível. Sem muitas abstrações. Apenas algumas de qualidade de vida, como disse.

Sobre -nostdlib, não. Teremos libs std bem trabalhadas.

já o __attribute__, depende. Teremos sim, os atributos do C, mas, de forma mais simples. Isso vai ser consequência da "qualidade de vida do Carla", exemplo:

int32 foo = () naked {
    return 2;
}

int32 main = () {
    return foo();
}

Em relação ao modelo de memória, Carla usará Arenas de memória combado com um defer para desalocação ao pop do escopo.

E sim, também será compatvel com alocação 100% manual, assim como Rust, Zig e C++ são.

string name = arena.alloc(128);
defer arena.dump(name);

-- resto do código

Sobre a performance de compilação, o Runa não faz muitas coisas. Ele é reponsável por adaptar a sintaxe do Assembly para a arquitetura ou assembler específico. Claro, que se o usuário quiser ele pode e deve delegar mais funções ao Runa. Mas nos extensors oficiais é o mínimo possível. Grande parte das coisas processadas em tempo de compilação estão dentro do core C++ do Morgana.

Até o momento não realizei benchmarks, mas tenho absoluta certeza que se o comptime ficar pior em um projeto pequeno, em um grande nunca será pior, o que ainda sim gera vantagem.

Além de que, nos meus testes de performance do Runa (que estes sim eu realizei), o Runa chegava ser até 3x mais rápido em algumas situações do que o Lua oficial. Depois trarei mais dados sobre isto.

Muito obrigado pelo review!

Edit. Sobre as docs, eu removi. Por que ainda não tenho a sintaxe 100% estabelecida. Alguns detalhes MINIMOS ainda estão sendo decididos. Tipo:

  • Devo usar parênteses no if?
  • Devo implementar tipagem "automatica" com auto como C++ ou let?
  • Em caso de ser um let, devo implementa-lo por padrão constante e permiti-lo ser mutável com mut tal como Rust?
  • Quando o tipo é definido em tempo de compilação, devo usar := ou mantenho = ?

Estes são alguns dos exemplos.

Carregando publicação patrocinada...
2

Legal demais a ideia de arena + defer.

Sobre auto, tenho sentimentos mistos. Ótimo quando o tipo está evidente no RHS, perigoso quando começa a esconder informação. Então talvez isso seja algo que a própria linguagem possa restringir melhor, não só deixar para “code standart". Sobre := vs =, eu tenderia a deixar explícito.

E sobre o “mais baixo nível que C” / “as good as Rust”: eu entendi melhor agora o que você quis dizer, mas eu tomaria bastante cuidado com essas frases. Como marketing elas são fortes, mas em comunidade técnica/científica o pessoal cobra é precisão.

C já é um wrapper para assembly. Mas muita coisa para controlar o binário gerado tipo alinhamento, seções, naked, freestanding fica espalhado entre atributos específicos do compilador, flags e convenções da toolchain. Então talvez a tese da Carla seja pegar essas coisas que em C são meio "escondidas" e tornar elas primitivas de primeira classe. E deixar isso claro para defender a alegação.

Carla tenta ser “mais baixo nível que C” porque torna explícito na linguagem controle que em C fica implícito na toolchain.

Sobre “Good as Rust”, eu evitaria essa formulação. “Good” é subjetivo demais e abre uma guerra religiosa desnecessária, tem gente que nem acha Rust bom rs (yours truly). Rust só é "bom" porque entrega segurança de memória sem GC.

Carla oferece segurança de memória por arenas e escopos sem trazer toda a complexidade do modelo de ownership do Rust.

Isso é uma promessa técnica bem mais precisa e talvez até mais interessante.

E a melhor dica que posso te dar: não subestime documentação. Não deixa para documentar só quando “a sintaxe estiver pronta”, porque linguagem nunca fica pronta (C++ está aí para provar). Vai deixando a documentação evoluir junto com a implementação. Mesmo que seja provisório, escreva design docs. No mínimo vão te ajudar a pensar melhor.

1

Ótimos colamentos sobre o "auto", levarei em consideração!

E sobre o “mais baixo nível que C” / “as good as Rust”: eu entendi melhor agora o que você quis dizer, mas eu tomaria bastante cuidado com essas frases. Como marketing elas são fortes, mas em comunidade técnica/científica o pessoal cobra é precisão.

Eu pretendo ainda mudar um pouco essa proposta para deixar mais clara, você não é a primeira que comentou sobre isto. E, vocês estão certos. é muito genérico. Não diz muito sobre a proposta da linguagem, e pode soar como a nomenclatura usada por você: "Marketing forte."

C já é um wrapper para assembly. Mas muita coisa para controlar o binário gerado tipo alinhamento, seções, naked, freestanding fica espalhado entre atributos específicos do compilador. [...]

Este é apenas um dos pontos que quero mudar. Eu não vejo por que termos structs que a ordem dos campos altera a quantidade de bytes ocupados na stack. Não vejo por que termos tanta abstração em cima de estruturas de dados. Tudo deve ser "raw" em Carla.

E, claro, mantendo a tão dita "qualidade de vida do Rust/C++".

Sobre “Good as Rust”, eu evitaria essa formulação. “Good” é subjetivo demais e abre uma guerra religiosa desnecessária, tem gente que nem acha Rust bom rs (yours truly). Rust só é "bom" porque entrega segurança de memória sem GC.

Na verdade, como dito, isso será mudado. Mas, o "Good as Rust" quer dizer:

Não te deixar ser burro tal como Rust. Segurança de memória implementada de forma nativa ao máximo possível, mas que não afetará a sua responsabilidade de "assegurar" a segurança do seu código. Tal como C++, por exemplo.

A oferta de alocadores customizados em Rust, e a simplicidade da criação destes alocadores também são algo que pretendo trazer par ao Carla.

E a melhor dica que posso te dar: não subestime documentação. Não deixa para documentar só quando “a sintaxe estiver pronta”, porque linguagem nunca fica pronta (C++ está aí para provar). Vai deixando a documentação evoluir junto com a implementação. Mesmo que seja provisório, escreva design docs. No mínimo vão te ajudar a pensar melhor.

Não irei. Ainda não esta implementada pelos motivos que eu te citei acima, mas ainda há mais um: O projeto está migrando da fase "imatura", para a fase "matura", agora. E isto não foi minha prioridade agora. Eu estava focado na compatibilidade com Windows até ontem.

Ainda não consegui distinguir quais pronomes usar para você, usei o feminino, peço desculpas caso não seja uma mulher. (O username me parece mais feminino)