He estado aprendiendo zig para mi proyecto de desarrollo de juegos, lee más sobre esto aquí. Esas son mis impresiones iniciales (en su mayoría positivas) del lenguaje, provenientes de una experiencia reciente en su mayoría JS/TS.

Manejo de errores

Los errores son valores - Es una opinión bastante popular en este momento que las excepciones no son las mejores. Crean un flujo de control oculto y en JavaScript ni siquiera se pueden declarar; lo que hace que tus aplicaciones sean mucho más inestables.

Zig usa enumeraciones de errores y un agradable azúcar sintáctico para un manejo de errores fácil y divertido. Por ejemplo :

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

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

En el código anterior declaramos un error MyError (esto también se puede hacer por separado) y lo devolvemos.
El intento significa "si esto devuelve un error, devuélvalo aquí" como en:

failingFunction() catch |err| return err;

Creo que este enfoque es una gran combinación y nos salva del interminable if (err! = nil) en Go land.

Otros aspectos destacados:

• Los errores son explícitos, todos los tipos deben declararse y manejarse
• El manejo se realiza en ese mismo momento, no a nivel de bloque
• Gracias a la captura de carga útil, los errores se escriben correctamente y se completan automáticamente, lo que facilita el uso de algo como una expresión de cambio.

La sintaxis !void - ! se utiliza para crear una unión entre el tipo de devolución y los tipos de error. Zig admite no agregar ningún error antes de !, lo que se supone que crea una unión de todos los errores que realmente devuelve la función.

En la práctica, esta sintaxis no me resulta útil. Al menos con mi experiencia en IDE, en este caso no obtengo ningún sentido inteligente y eso hace que la función sea menos clara. ¡Solo dime qué vas a devolver!
Sólo veo que es útil en la función main().

captura de carga útil

Sabes que en TS puedes tener un tipo como número | ¿indefinido? Puede usar un if o alguna lógica para limitar el tipo a lo que necesita, y TS mostrará automáticamente el nuevo tipo correctamente.
Si bien es fácil, existen problemas con este enfoque:

• Si los tipos pueden cambiar a lo largo de una función, es más difícil de seguir
• En algunos casos aún hay que hacer un yeso

En Zig, esto se hace con "Captura de carga útil". Puede "capturar", también conocido como crear una nueva variable inmutable con el tipo resultante. Por ejemplo:

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

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

¡Está muy claro lo que está pasando! Además, la variable es inmutable, pero si realmente necesita cambiarla, puede capturar un puntero al valor.

También vale la pena mencionar que este mecanismo se puede utilizar en todo el lenguaje, incluyendo: for, switch, catch, etc.

travesuras de comptime

Es cierto que todavía no entendía todas las posibilidades del comptime. Pero en resumen, puedes ejecutar código normal durante la compilación. Puede crear funciones completas que solo se utilizan durante este tiempo y pueden devolver errores de compilación si es necesario.

Se adapta bastante bien a Zig, porque es un lenguaje muy maleable. Incluso los tipos son valores, lo que significa que puedes crear, cambiar y obtener información sobre los tipos (especialmente en comptime).

Un ejemplo básico de esto de la Guía Zig:

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




  
  
  Experiencia del editor


Estoy usando VSCode con el complemento oficial Zig (que usa zls). El intellisense y los errores que veo en el editor dejan mucho que desear.

"comportamiento ilegal detectable", también conocidos como cosas ilegales que resultarán en un error de compilación, normalmente no se muestran en el editor. Por ejemplo:



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




Estoy en la versión de la rama maestra 0.14 (dev), si se supone que funciona, ¡déjamelo saber en los comentarios!