Tenho aprendido zig para meu projeto de desenvolvimento de jogos, leia mais sobre isso aqui. Essas são minhas impressões iniciais (em sua maioria positivas) da linguagem, provenientes de uma experiência recente principalmente em JS/TS.

Tratamento de erros

Erros são valores - É uma opinião bastante popular neste momento que as exceções não são as melhores. Eles criam um fluxo de controle oculto e em JavaScript nem podem ser declarados; o que torna seus aplicativos muito mais instáveis.

Zig usa enums de erros e um bom açúcar sintático para um tratamento de erros fácil e divertido. Por exemplo :

fn failingFunction() error{MyError}!void {
    return error.MyError;
}

pub fn main() !void {
    try failingFunction();
}

No código acima declaramos um erro MyError (Isso também pode ser feito separadamente) e o retornamos.
O try significa "se retornar um erro, retorne aqui" como em:

failingFunction() catch |err| return err;

Acredito que essa abordagem é uma ótima combinação e nos salva do interminável if (err!=nil) em Go land.

Outros destaques:

• Os erros são explícitos, todos os tipos devem ser declarados e tratados
• O tratamento é feito ali mesmo, não no nível do bloco
• Graças à captura de carga útil, os erros são digitados corretamente e preenchidos automaticamente, facilitando o uso de algo como uma expressão switch.

A sintaxe !void - ! é usado para criar uma união entre o tipo de retorno e os tipos de erro. O Zig suporta a não adição de erros antes do !, o que supostamente cria uma união de todos os erros que você realmente retorna da função.

Na prática, considero essa sintaxe inútil. Pelo menos com minha experiência em IDE, não entendo nenhum sentido neste caso e isso torna a função menos clara. Apenas me diga o que você vai devolver!
Só vejo que é útil na função main().

Captura de carga útil

Você sabe como no TS você pode ter um tipo como number | indefinido? Você pode usar um if ou alguma lógica para restringir o tipo ao que você precisa, e o TS exibe automaticamente o novo tipo corretamente.
Embora seja fácil, há problemas com esta abordagem:

• Se os tipos podem mudar ao longo de uma função, é mais difícil segui-los
• Em alguns casos você ainda precisa fazer um elenco

No Zig, você faz isso com "Payload Capturing". Você pode "capturar", também conhecido como criar uma nova variável imutável com o tipo resultante. Por exemplo:

const maybe_num: ?usize = 10; // `?` Means it can be `null`

if (maybe_num) |num| {
    // Use num
}

Está muito claro o que está acontecendo! Além disso, a variável é imutável, mas se você realmente precisar alterá-la, poderá capturar um ponteiro para o valor.

Vale ressaltar também que esse mecanismo pode ser utilizado em toda a linguagem, incluindo: for, switch, catch, etc.

Travessuras do Comptime

Reconheço que ainda não compreendi todas as possibilidades do Comptime. Mas, resumindo, você pode executar código normal durante a compilação. Você pode criar funções inteiras que serão usadas apenas durante esse período e retornar erros de compilação, se necessário.

Combina muito bem com Zig, porque é uma linguagem muito maleável. Mesmo os tipos são valores, o que significa que você pode criar, alterar e obter informações sobre os tipos (especialmente em tempo de compilação).

Um exemplo básico disso no Guia Zig:

const a = 5; // When a number type isn't specified, it defaults to comptime_int
const b: if (a 




  
  
  Experiência do editor


Estou usando o VSCode com o plugin Zig oficial (que usa zls). O intellisense e os erros que vejo no editor deixam muito a desejar.

"comportamento ilegal detectável", também conhecido como coisas ilegais que resultarão em um erro de compilação, normalmente não são exibidos no editor. Por exemplo:



const nums = [3]u8{ 2, 1, 3 };
_ = nums[4]; // Index out of bounds error




Estou na versão 0.14 (dev) master branch, se funcionar, me avise nos comentários!