Forem: Paolo Carraro

Building an Actor Model lib in Go

Paolo Carraro — Mon, 09 Mar 2026 22:07:19 +0000

While researching Gleam and Elixir, I came across this architectural pattern which I later discovered is used in other languages as well. Fascinated by the promise of clean and robust development, I tried to create a library called Cinecity to better understand it, and to deepen my knowledge of Go with channels.

Interactions within the application

The basic idea is intuitive and already seen in other frameworks:
isolated components, manage their own state, exchanging only messages.

The postman and actors

Going deeper into the library, the first structure to instantiate is Postman, which is the manager of the actors map in play and handles message forwarding using channels.
The next step is to create actors by providing the structure that handles the state, which must implement the StateProcessor interface, and the address to reach the actor itself.

// init postman for first
actor.InitPostman()

// set an address for actor
whAddr := actor.NewAddress("local", "warehouse")
// spawn an actor by an address and its own state
warehouseActor, err := actor.RegisterActor(
    whAddr,
    NewWarehouseState(),
)

// prepare the message for warehouse actor
msg := actor.NewMessage(
    whAddr,
    nil,
    AddNewProductPayload{Product{Code: "ABC", Quantity: 5}},
)

// send the message
err := actor.SendMessage(msg)

Processing messages

Messages forwarded to the actor will be processed by distinguishing the message content by evaluating its type. This is handled by Process, which is the most important method exposed by StateProcessor. Let's see an example with two types of messages handled where the second returns a response to the sender:

func (sp *stateProcessor) Process(msg actor.Message) {
    switch body := msg.Body.(type) {
    case AddNewProduct:
        createProduct(body.Name, body.Category)
    case GetProduct:
      prdBody, err := getProduct(body.ProductID)
        if msg.WithResponse {
            returnMsg := actor.NewReturnMessage(prdBody, msg, err)
            msg.ResponseChan <- returnMsg
        }
    }
}

Batch management

We might need to process a message not immediately but by aggregating multiple messages and then proceeding with processing to avoid overloading state updates: in this case we can use the Batcher:

// on init state processor function create a new batcher
// set timeout, max messages for starting process, handler function
b := batch.NewBatcher(5000, 5, s.updateAggregateState)
stateProcessor.batcher = b

// on process message
func (state *StateProcessor) Process(msg actor.Message) {
    switch msg.Body.(type) {
    case store.StoreEventAddedBody:
        state.batcher.Add(msg)
    }
}

Broadcast a message to many

To send a message to multiple actors at once, we can use the BroadcastMessage method which also accepts a filter to select the actors to reach, represented by the area defined in the address.

msg := actor.NewBroadcastMessage(fromAddr, "broadcast message body")
numSent := actor.BroadcastMessage(msg, "warehouse")

Subscribe to a message

We might need to be notified when a certain event occurs in an actor's state. To achieve this behavior, we need to initialize a helper structure named Subscriptions which is itself an actor. Our StateProcessor will instantiate this actor to pass all messages that arrive to it, but the subscriber will only handle those reserved for it like AddSubscriptionMessageBody and RemoveSubscriptionMessageBody. The StateProcessor will instead decide what the condition is to notify its subscribers.

func (sp *stateProcessor) Process(msg actor.Message) {
    // manage add and remove subscription
    m.notifier.Process(msg)

    switch payload := msg.Body.(type) {
    // notify subscribers
    case TriggerSubscriptionNotifierBodyMsg:
        subsMsg := subscriber.NewSubscribersMessage(msg.To, "hello subscribers!")
        m.notifier.NotifySubscribers(subsMsg)

Send messages to other applications

In addition to internal application usage, you can also use the configuration option to connect other applications using a NATS server.

// create NATS connection (this must do for every app that wants receive and send remotely)
natsToken := os.Getenv("NATS_SECRET")
nc := nats.Connect(nats.DefaultURL, nats.Token(natsToken))

// define body type that will be received from remote apps
reg := actor.EnvelopePayloadTypeRegistry{
    "domain.MsgBody": reflect.TypeOf(domain.MsgBody{}),
}

// init postman with outbound option
actor.InitPostman(actor.WithOutboundMessageService("dept-products", nc, reg))

// init a outbound address
toAddress := actor.NewOutboundAddress("dept-warehouse", "warehouse", "actor-dispatcher")
fromAddress := actor.NewAddress("local", "actor-product")
rmsg := actor.NewMessage(
    toAddress,
    fromAddress,
    MsgBody{Text: "hello from products dept"},
)

err = actor.SendMessage(rmsg)

Let it crash?

In Erlang/Elixir, one of the characteristics that made it famous for its robustness is that processes are truly separated and a crash of one of them can be handled by a supervisor that coordinates whether it should be restarted and how. This is obviously missing in Cinecity since the application is a single process and channels only serve for coordinating concurrency in message handling, while errors are returned where possible.

Usage

For now, my usage has been modest, so I cannot yet give a judgment on effectiveness, development experience, and performance. So far, the experience during its implementation has been very interesting even though the patterns were simple (message sending, subscribers, batcher).
If you are interested in the subject, I invite you to also look at other well-made libraries like Hollywood, actor-model, but also Watermill, and if you are interested, I gladly accept collaborations, PRs and issues.

Zig vs Go: interfaces

Paolo Carraro — Tue, 17 Feb 2026 22:02:42 +0000

(you can find previous post about same topic here)

Polymorphism through interfaces is handled differently between Zig and Go. While Go defines an interface keyword and proposes a very lightweight implementation translated into a motto like "if it looks like a duck, then it is one", in Zig there is no dedicated syntax and therefore one must resort to structures and compile-time generation.

Let's see a first example of polymorphism between two models that have common methods and can be collected together.

The Go Approach

First, let's define the interface

type Priceable interface {
    GetTotalPrice() uint16
    IsSKU() bool
}

Let's define the structures that represent the entities we need to manage

type SKU struct {
    ID    string
    Price uint16
}

type Product struct {
    Code     string
    Quantity uint32
    Skus     []SKU
}

In Go, to implement the Priceable interface, it's enough to define methods for the 2 structures and these will automatically implement the interface

func (s *SKU) GetTotalPrice() uint16 {
    return s.Price
}

func (s *SKU) IsSKU() bool {
    return true
}

func (p *Product) GetTotalPrice() uint16 {
    var result uint16
    for _, s := range p.Skus {
        result += s.GetTotalPrice()
    }
    return result * uint16(p.Quantity)
}

func (p *Product) IsSKU() bool {
    return false
}

We just need to instantiate the entities and we can use the common methods

func main() {
    sku1 := SKU{
        ID:    "1",
        Price: 150,
    }

    sku2 := SKU{
        ID:    "2",
        Price: 250,
    }

    product := Product{
        Code:     "product1",
        Quantity: 1,
        Skus:     []SKU{sku1, sku2},
    }

    items := []Priceable{
        &sku1,
        &sku2,
        &product,
    }

    for _, item := range items {
        if !item.IsSKU() {
            fmt.Println(item.GetTotalPrice())
        }
    }
}

In Zig there are at least 2 ways to approach the problem.

First, let's define the two structs to represent the entities to manage and their related methods

const SKU = struct {
    id: []const u8,
    price: u16,

    pub fn getTotalPrice(self: *const SKU) u16 {
        return self.price;
    }

    pub fn isSku(_: *const SKU) bool {
        return true;
    }
};

const Article = struct {
    code: []const u8,
    quantity: u16,
    skus: []*const SKU,

    pub fn getTotalPrice(self: *const Article) u16 {
        var result: u16 = 0;
        for (self.skus) |sku| {
            result += sku.getTotalPrice();
        }

        return result * self.quantity;
    }

    pub fn isSku(_: *const Article) bool {
        return false;
    }
};

Tagged Union

With this approach, we'll group the possible types that we collect with a union which specifically is of type tagged, meaning with an enum that explicitly defines the fields. The union itself will expose methods in which we'll distinguish the types to be able to call the methods we're interested in; in this case they correspond as signatures but could obviously be different since we've already distinguished the type upstream.
The disadvantage in this case is that every type added to the union will need to be propagated in the various exposed methods. Let's see an example:

// define enum
const PriceItemEnum = enum {
    sku,
    article,
};

// define tagged union, enum type is optional because it can be inferred
const PriceItemType = union(PriceItemEnum) {
    sku: SKU,
    article: Article,

    pub fn getTotalPrice(self: PriceItemType) u16 {
        // distinguish the type by enum
        return switch (self) {
            // value is captured by pointer
            .sku => |*s| s.getTotalPrice(),
            .article => |*a| a.getTotalPrice(),
        };
    }

    pub fn isSku(self: PriceItemType) bool {
        // in this case struct method is not used
        return switch (self) {
            .sku => true,
            .article => false,
        };
    }
};

const s1: SKU = .{
    .id = "1",
    .price = 150,
};

const s2: SKU = .{
    .id = "2",
    .price = 250,
};

var skus = [_]*const SKU{ &s1, &s2 };
const a: Article = .{
    .code = "article1",
    .quantity = 2,
    .skus = &skus,
};

// collection definition with unions
const itemsB = [_]PriceItemType{ .{ .sku = s1 }, .{ .sku = s2 }, .{ .article = a } };
for (itemsB) |itemb| {
    if (!itemb.isSku()) {
        std.debug.print("{d}\n", .{itemb.getTotalPrice()});
    }
}

Interface-like

This approach makes the usage experience more similar to how interfaces are used and is used in Zig, for example, for memory allocators.

// Define the "interface" struct
const Priceable = struct {
    // Opaque pointer where reference concrete implementation
    ptr: *const anyopaque,

    // Function pointers for interface methods
    getTotalPriceFn: *const fn (ptr: *const anyopaque) u16,
    isSkuFn: *const fn (ptr: *const anyopaque) bool,

    // ------------------------------------------------------------
    // Interface methods: re-dispatch to concrete implementation
    pub fn getTotalPrice(self: *const Priceable) u16 {
        return self.getTotalPriceFn(self.ptr);
    }

    pub fn isSku(self: *const Priceable) bool {
        return self.isSkuFn(self.ptr);
    }
    // ------------------------------------------------------------

    // Generic constructor: creates interface from any concrete type
    pub fn init(pointer: anytype) Priceable {
        // Extract concrete type at compile time
        const T = @TypeOf(pointer);
        // Extract pointer type information
        const ptrInfo = @typeInfo(T);

        // Generate type-specific wrapper functions at compile time
        const concreteMethods = struct {
            pub fn getTotalPrice(ptr: *const anyopaque) u16 {
                // Cast opaque ptr to concrete type and call method
                const self: T = @ptrCast(@alignCast(ptr));
                return ptrInfo.pointer.child.getTotalPrice(self);
            }

            pub fn isSku(ptr: *const anyopaque) bool {
                // Cast opaque ptr to concrete type and call method
                const self: T = @ptrCast(@alignCast(ptr));
                return ptrInfo.pointer.child.isSku(self);
            }
        };

        // Return interface struct that wraps concrete implementation 
        return Priceable{
            // Cast concrete type to opaque pointer
            .ptr = @ptrCast(pointer),
            .getTotalPriceFn = concreteMethods.getTotalPrice,
            .isSkuFn = concreteMethods.isSku,
        };
    }
};

Certainly, at first glance this implementation seems complex, and to some extent it is when compared to Go, but the advantage is that everything is resolved at compile-time since in the init method we use the anytype keyword which forces resolution at compilation: this means that at runtime we have no type of reflection and therefore no abstraction to resolve. A use case like this is very useful when we have heterogeneous collections and don't need to know the types in advance, but only need to implement the methods which, if missing, would be identified by the compiler as an error. Note the pointer casts in both directions, from unknown to concrete and vice versa.
Let's complete the example with the use of this approach to polymorphism using the same implementations of Article and SKU used for the example with tagged unions.

const s1Priceable = Priceable.init(&s1);
const s2Priceable = Priceable.init(&s2);
const aPriceable = Priceable.init(&a);
const items = [_]*const Priceable{ &s1Priceable, &s2Priceable, &aPriceable };
for (items) |item| {
    if (!item.isSku()) {
        std.debug.print("{d}\n", .{item.getTotalPrice()});
    }
}

One of the best posts to fully understand all the details about this last approach can be found here.

Zig vs Go: interfaces

Paolo Carraro — Tue, 17 Feb 2026 22:02:42 +0000

(you can find previous post about same topic here)

Let's see a first example of polymorphism between two models that have common methods and can be collected together.

The Go Approach

First, let's define the interface

type Priceable interface {
    GetTotalPrice() uint16
    IsSKU() bool
}

Let's define the structures that represent the entities we need to manage

type SKU struct {
    ID    string
    Price uint16
}

type Product struct {
    Code     string
    Quantity uint32
    Skus     []SKU
}

In Go, to implement the Priceable interface, it's enough to define methods for the 2 structures and these will automatically implement the interface

func (s *SKU) GetTotalPrice() uint16 {
    return s.Price
}

func (s *SKU) IsSKU() bool {
    return true
}

func (p *Product) GetTotalPrice() uint16 {
    var result uint16
    for _, s := range p.Skus {
        result += s.GetTotalPrice()
    }
    return result * uint16(p.Quantity)
}

func (p *Product) IsSKU() bool {
    return false
}

We just need to instantiate the entities and we can use the common methods

func main() {
    sku1 := SKU{
        ID:    "1",
        Price: 150,
    }

    sku2 := SKU{
        ID:    "2",
        Price: 250,
    }

    product := Product{
        Code:     "product1",
        Quantity: 1,
        Skus:     []SKU{sku1, sku2},
    }

    items := []Priceable{
        &sku1,
        &sku2,
        &product,
    }

    for _, item := range items {
        if !item.IsSKU() {
            fmt.Println(item.GetTotalPrice())
        }
    }
}

In Zig there are at least 2 ways to approach the problem.

First, let's define the two structs to represent the entities to manage and their related methods

const SKU = struct {
    id: []const u8,
    price: u16,

    pub fn getTotalPrice(self: *const SKU) u16 {
        return self.price;
    }

    pub fn isSku(_: *const SKU) bool {
        return true;
    }
};

const Article = struct {
    code: []const u8,
    quantity: u16,
    skus: []*const SKU,

    pub fn getTotalPrice(self: *const Article) u16 {
        var result: u16 = 0;
        for (self.skus) |sku| {
            result += sku.getTotalPrice();
        }

        return result * self.quantity;
    }

    pub fn isSku(_: *const Article) bool {
        return false;
    }
};

Tagged Union

// define enum
const PriceItemEnum = enum {
    sku,
    article,
};

// define tagged union, enum type is optional because it can be inferred
const PriceItemType = union(PriceItemEnum) {
    sku: SKU,
    article: Article,

    pub fn getTotalPrice(self: PriceItemType) u16 {
        // distinguish the type by enum
        return switch (self) {
            // value is captured by pointer
            .sku => |*s| s.getTotalPrice(),
            .article => |*a| a.getTotalPrice(),
        };
    }

    pub fn isSku(self: PriceItemType) bool {
        // in this case struct method is not used
        return switch (self) {
            .sku => true,
            .article => false,
        };
    }
};

const s1: SKU = .{
    .id = "1",
    .price = 150,
};

const s2: SKU = .{
    .id = "2",
    .price = 250,
};

var skus = [_]*const SKU{ &s1, &s2 };
const a: Article = .{
    .code = "article1",
    .quantity = 2,
    .skus = &skus,
};

// collection definition with unions
const itemsB = [_]PriceItemType{ .{ .sku = s1 }, .{ .sku = s2 }, .{ .article = a } };
for (itemsB) |itemb| {
    if (!itemb.isSku()) {
        std.debug.print("{d}\n", .{itemb.getTotalPrice()});
    }
}

Interface-like

This approach makes the usage experience more similar to how interfaces are used and is used in Zig, for example, for memory allocators.

// Define the "interface" struct
const Priceable = struct {
    // Opaque pointer where reference concrete implementation
    ptr: *const anyopaque,

    // Function pointers for interface methods
    getTotalPriceFn: *const fn (ptr: *const anyopaque) u16,
    isSkuFn: *const fn (ptr: *const anyopaque) bool,

    // ------------------------------------------------------------
    // Interface methods: re-dispatch to concrete implementation
    pub fn getTotalPrice(self: *const Priceable) u16 {
        return self.getTotalPriceFn(self.ptr);
    }

    pub fn isSku(self: *const Priceable) bool {
        return self.isSkuFn(self.ptr);
    }
    // ------------------------------------------------------------

    // Generic constructor: creates interface from any concrete type
    pub fn init(pointer: anytype) Priceable {
        // Extract concrete type at compile time
        const T = @TypeOf(pointer);
        // Extract pointer type information
        const ptrInfo = @typeInfo(T);

        // Generate type-specific wrapper functions at compile time
        const concreteMethods = struct {
            pub fn getTotalPrice(ptr: *const anyopaque) u16 {
                // Cast opaque ptr to concrete type and call method
                const self: T = @ptrCast(@alignCast(ptr));
                return ptrInfo.pointer.child.getTotalPrice(self);
            }

            pub fn isSku(ptr: *const anyopaque) bool {
                // Cast opaque ptr to concrete type and call method
                const self: T = @ptrCast(@alignCast(ptr));
                return ptrInfo.pointer.child.isSku(self);
            }
        };

        // Return interface struct that wraps concrete implementation 
        return Priceable{
            // Cast concrete type to opaque pointer
            .ptr = @ptrCast(pointer),
            .getTotalPriceFn = concreteMethods.getTotalPrice,
            .isSkuFn = concreteMethods.isSku,
        };
    }
};

const s1Priceable = Priceable.init(&s1);
const s2Priceable = Priceable.init(&s2);
const aPriceable = Priceable.init(&a);
const items = [_]*const Priceable{ &s1Priceable, &s2Priceable, &aPriceable };
for (items) |item| {
    if (!item.isSku()) {
        std.debug.print("{d}\n", .{item.getTotalPrice()});
    }
}

One of the best posts to fully understand all the details about this last approach can be found here.

Zig vs Go: generics

Paolo Carraro — Mon, 09 Feb 2026 23:07:41 +0000

(you can find previous post about same topic here)

Go introduces generics only starting from version 1.18 following numerous requests from the community: from this version, Go allows parameterizing the types of functions and structures in order to avoid code redundancy.
Zig does not provide a syntax for generics but uses one of its peculiar features, namely the generation and/or manipulation of code at compile time (metaprogramming) with the use of the comptime keyword. The advantage is to obtain a binary without overhead for type checking during runtime.

Using generics in functions

Let's see how to define a function that accepts multiple types

// Go
func doubleNumber[T constraints.Integer | constraints.Float](a T) T {
    return a * T(2)
}
...
doubledFloat := doubleNumber[float32](5.3)
fmt.Println(doubledFloat)
// type parameter inferred
doubledInteger := doubleNumber(5)
fmt.Println(doubledInteger)

// Zig 
fn doubleNumber(comptime T: type, a: T) T {
    return a * 2;
}
...
const doubledFloat = doubleNumber(f32, 5.3);
std.debug.print("{}\n", .{doubledFloat});
const doubledInteger = doubleNumber(i32, 5);
std.debug.print("{}\n", .{doubledInteger});

Note that in Go the generic is defined through its constraints which are interfaces that allow the compiler to check if a type does not respect the interface, while Zig evaluates any compilation errors during the compile-time phase when it actually tries to create the function for the type indicated by the caller.

Using generics in structure definitions

In Go, also for structs we can indicate one or more types with the same syntax and rules we use for functions.

// Go
type Stack[T any, Q any] struct {
    Items      []T
    AlterItems []Q
    Index      int
}
...
intStack := Stack[int8, float32]{
    Items:      []int8{1, 2, 3, 4, 5},
    AlterItems: []float32{1.1, 2.1, 3.1, 4.7, 5.3},
    Index:      4,
}
fmt.Println(
  intStack.Items[intStack.Index], 
  intStack.AlterItems[intStack.Index]
)

strStack := Stack[string, bool]{
    Items:      []string{"hello", "gophers"},
    AlterItems: []bool{false, true},
    Index:      0,
}
fmt.Println(
  strStack.Items[strStack.Index], 
  strStack.AlterItems[strStack.Index]
)

In Zig, to obtain a struct with parameterized type fields, use a function that returns type and is therefore resolved at compile time.

// Zig 
fn Stack(comptime T: type, comptime Q: type) type {
    return struct {
        items: []const T,
        alterItems: []const Q,
        index: usize,
    };
}
...
const intArr = [_]i32{ 1, 2, 3, 4, 5 };
const floatArr = [_]f32{ 1.1, 2.1, 3.1, 4.7, 5.3 };
const intStack = Stack(i32, f32){
    .items = intArr[0..],
    .alterItems = floatArr[0..],
    .index = 4,
};
std.debug.print("{d} {d}\n", 
    .{ intStack.items[intStack.index],
       intStack.alterItems[intStack.index]
    });

const strArr = [_][]const u8{ "hello", "ziguanas" };
const boolArr = [_]bool{ false, true };
const strStack = Stack([]const u8, bool){
    .items = &strArr,
    .alterItems = &boolArr,
    .index = 1,
};
std.debug.print("{s} {}\n", 
    .{ strStack.items[strStack.index],
       strStack.alterItems[strStack.index]
    });

Structs as generics

In Go, constraints are interfaces, so in a function that accepts structs as parameters, they must at least implement the methods used within the function block

type IdTrackable interface {
    GetID() string
}

type Article struct {
    ID       string
    Name     string
    Category string
}
func (a Article) GetID() string { return a.ID }

type SKU struct {
    ID        string
    ArticleID string
    Available bool
}
func (s SKU) GetID() string { return s.ID }

func findById[T IdTrackable](items []T, id string) (*T, error) {
    for _, item := range items {
        if item.GetID() == id {
            return &item, nil
        }
    }
    return nil, errors.New("not found")
}
...
articles := []Article{
    {
        ID:       "a1",
        Name:     "Laptop",
        Category: "Electronics",
    },
    {
        ID:       "a2",
        Name:     "Book",
        Category: "Education",
    },
}

article, err := findById(articles, "a1")
if err == nil {
    fmt.Printf("Found article: %+v\n", *article)
}

In Zig, this function with the generic will be resolved and duplicated at compile time as many times as a different type is passed in its call.

// Zig
const Article = struct {
    id: []const u8,
    name: []const u8,
    category: []const u8,
};

const SKU = struct {
    id: []const u8,
    articleId: []const u8,
    available: bool,
};

fn findById(comptime T: type, items: []const T, idx: []const u8) !T {
    for (items) |item| {
        if (std.mem.eql(u8, @field(item, "id"), idx)) {
            return item;
        }
    }
    return error.NotFound;
}
...
const articles = [_]Article{
    .{
        .id = "a1",
        .name = "Laptop",
        .category = "Electronics",
    },
    .{
        .id = "a2",
        .name = "Book",
        .category = "Education",
    },
};

const art = try findById(Article, &articles, "a2");
std.debug.print("Found article: {}\n", .{art});

The use of metaprogramming proposed by Zig, with its own syntax and rules, reveals many other potentials beyond the resolution of generics that are currently not achievable with Go.

Zig vs Go: errors

Paolo Carraro — Sun, 25 Jan 2026 23:05:31 +0000

(you can find previous post about same topic here)

Errors are values

As in Go, errors in Zig are also handled as values, but while in Go we can indicate that a function returns multiple values, so one of them could be a pointer to an error, in Zig instead we declare a sort of union called error union type: the ! symbol that precedes the type returned by a function indicates that we might get an error. We can also have a precise indication of the error type that is defined as an enum if in addition to the ! we also have the type specification.

// Go
func canFail(num int) (int, error) {
    if num > 10 {
        return num, errors.New("input is greater than max (10)") 
    }
    return num, nil
}

// Zig
fn canFail(num: i8) !i8 {
    if (num > 10) {
        return error.InputIsGreaterThanMax;
    }
    return num;
}

We can notice that the substantial differences lie in the fact that Zig returns the value of an enum (declared inline in this example) and that this is not coupled with the result but is mutually exclusive; this is better seen by observing how it is handled.

// Go
result, err := canFail(val)
if err != nil {
        fmt.Printf("An error occurs: %v\n", err)
        os.Exit(1)
    }
// handle result value

// Zig
const result = canFail(num) catch |err| {
    std.debug.print("An error occurs: {}\n", .{err});
    return err;
};
// handle result value

In Zig it is also possible to use a more concise formula when the error should not be handled but only returned to the previous step:

const result = try canFail(num);
// handle result value

try in this case is the compressed version of catch |err| return err.

Error declaration

In Go, an error is any struct that implements the Error() string method, and to create custom errors we use these approaches.

// Go
var (
    ErrMissingArgument     = errors.New("missing argument")
    ErrInvalidArgument     = errors.New("invalid argument")
)

type MaxValueValidation struct {
    Max     int
    Current int
}

func (v *MaxValueValidation) Error() string {
    return fmt.Sprintf("input %d is greater than max %d", v.Current, v.Max)
}

In Zig, however, the error is reduced to an enum that can be combined with other enums and the result used as an indication of possible return errors.

const InputError = error{
    WrongInput,
    MissingInput,
};

const ValidationError = error{
    InputGreaterThanMax,
};

const FailureError = InputError || ValidationError;

Here are two complete examples of error handling:

// Go

package main

import (
    "errors"
    "fmt"
    "os"
    "strconv"
)

var (
    ErrMissingArgument = errors.New("missing argument")
    ErrInvalidArgument = errors.New("invalid argument")
)

type MaxValueValidation struct {
    Max     int
    Current int
}

func (v *MaxValueValidation) Error() string {
    return fmt.Sprintf("input %d is greater than max %d", v.Current, v.Max)
}

func main() {
    args := os.Args
    if len(args) < 2 {
        fmt.Printf("An error occurs: %v\n", ErrMissingArgument)
        os.Exit(1)
    }

    val, err := strconv.Atoi(os.Args[1])
    if err != nil {
        fmt.Printf("An error occurs: %v\n", ErrInvalidArgument)
        os.Exit(1)
    }

    result, err := canFail(val)
    var validationError *MaxValueValidation
    if errors.As(err, &validationError) {
        fmt.Printf("Check input: %v\n", validationError)
        os.Exit(1)
    } else if err != nil {
        fmt.Printf("An error occurs: %s\n", err.Error())
        os.Exit(1)
    } else {
        fmt.Printf("The result is %d\n", result)
    }
}

func canFail(num int) (int, error) {
    if num > 10 {
        return num, &MaxValueValidation{Max: 10, Current: num}
    }
    return num, nil
}

// Zig
const std = @import("std");

const InputError = error{
    WrongInput,
    MissingInput,
};

const ValidationError = error{
    InputGreaterThanMax,
};

const FailureError = InputError || ValidationError;

pub fn main() !void {
    var args = std.process.args();
    _ = args.skip();

    const valueArg = args.next() orelse {
        std.debug.print("Error occurs: missing argument.\n", .{});
        return FailureError.MissingInput;
    };

    const num = std.fmt.parseInt(i8, valueArg, 10) catch |err| {
        std.debug.print("Error occurs: wrong input {}\n", .{err});
        return FailureError.WrongInput;
    };

    const result = try canFail(num);
    std.debug.print("The result is: {d}", .{result});
}

fn canFail(num: i8) FailureError!i8 {
    if (num > 10) {
        std.debug.print("input {d} is greater than max {d}\n", .{ num, 10 });
        return ValidationError.InputGreaterThanMax;
    }
    return num;
}

Zig vs Go: structs

Paolo Carraro — Thu, 22 Jan 2026 00:21:48 +0000

(you can find previous post about same topic here)

The organization of data models through structs is not very different between Zig and Go, as both don't follow a primarily OOP approach with classes, constructors, declared interface implementations, and methods. However, both provide ways to define functions that become methods available for all entities typed by the struct.

Defining a struct

Let's look at an example of defining a model:

// Go
// Exported due to capitalized first letter
type Synth struct {
    manufacturer string // private
    name         string // private
    IsAnalog     bool // public
    ControlsNum  int8 // public
}

// Zig
// Exported due to pub keyword
pub const Synth = struct {
    // all field are public
    manufacturer: []const u8,
    name: []const u8,
    is_analog: bool,
    controls_num: u8,
}

The first difference lies in the definition of what is public and what is not: in Zig, if the struct is in a different module, it must be marked as pub, while in Go it must have a capital letter as its first letter. As for struct fields, in Zig they are always all public.

Instantiating a struct

To instantiate a struct, in both languages, it is idiomatic to have a function that returns the struct, which can be initialized with any values passed to the function itself. Normally in Go a pointer is returned since the entity's lifecycle is managed by the garbage collector, while in Zig the value is returned since memory allocation will be handled by the caller.

// Go idiomatic constructor
func NewSynth(manufacturer string, name string, isAnalog bool, controlsNum int8) *Synth {
    return &Synth{
        manufacturer: manufacturer,
        name:         name,
        IsAnalog:     isAnalog,
        ControlsNum:  controlsNum,
    }

// Zig idiomatic constructor
pub const Synth = struct {
// ... omissis field definitions see above
    pub fn init(manufacturer: []const u8, name: []const u8, is_analog: bool, controls_num: u8) Synth {
        return .{
            .manufacturer = manufacturer,
            .name = name,
            .is_analog = is_analog,
            .controls_num = controls_num,
        };
    }
}

The use of dot notation .{} to instantiate the struct indicates that the type will be inferred from context, in this case from the return type specified by the function. Already in this second example, we can notice that in Zig, functions belonging to the struct type are defined inside it, and unlike struct fields, functions that you want to expose must also be preceded by the pub keyword.

Defining methods

Let's now define three methods with different access types and returns.

// Go struct methods 

// Private method returning a single value
func (s *Synth) getCompleteName() string {
    return fmt.Sprintf("%s %s", s.manufacturer, s.name)
}

// Public method with no return value
func (s *Synth) Play() {
    fmt.Printf("%s is playing!\n", s.getCompleteName())
}

// Public method returning multiple values
func (s *Synth) Info() (int8, bool) {
    return s.ControlsNum, s.IsAnalog
}

// Zig struct methods 
pub const Synth = struct {
// ... omissis fields and init definitions 
    // Private method returning either an error or a value
    fn getCompleteName(self: Synth, destination_buffer: []u8) ![]u8 {
        return try fmt.bufPrint(destination_buffer, "{s} {s}", .{ self.manufacturer, self.name });
    }

    // Public method that may return an error
    pub fn play(self: Synth) !void {
        var db: [128]u8 = undefined;
        const cn = try self.getCompleteName(&db);
        debug.print("{s} is playing!\n", .{cn});
    }

    // Public method returning multiple values
    pub fn info(self: Synth) struct { u8, bool } {
        return .{ self.controls_num, self.is_analog };
    }
}

We notice that in Zig, the first parameter is a reference to the struct instance itself: this is how the receiver is defined. In Go, instead, it is placed in parentheses before the function. In some cases, the return type includes the ! which in Zig is called an error union type: it declares that the caller must handle a possible error value in addition to the expected value. In case of error, this will be returned directly by the try instruction, captured from the return of fmt.bufPrint.

Constant parameters and pointer receivers

In Go, the entity's pointer is passed as the receiver so that, if modifications need to be made to the struct's values, they act on the struct itself and not on a copy. In Zig, parameters passed to a function are always constants, therefore if we want to modify a value we must pass the pointer as a constant and then treat it as such inside the function.

// Go
func (s *Synth) ChangeName(name string) {
    s.name = name
}

// Zig
pub fn changeName(self: *Synth, name: []const u8) void {
    self.name = name;
}

If we wanted to pass a parameter as a pointer for optimization reasons while also wanting to make it immutable, we can annotate it as *const Synth.

Zig vs Go: loops

Paolo Carraro — Sun, 18 Jan 2026 22:45:20 +0000

(you can find previous post about same topic here)

Comparing the loop syntax in Go and Zig, it's clear that the latter offers some additional possibilities in terms of expression and clarity about what's happening. Zig provides two keywords while and for, while in Go everything is solved with for.
As in previous posts, I'll try to present two scripts that achieve the same result, in this case starting from an array of 10 integers.

while loop

// Zig
const items = [10]i8{ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
var i: usize = 0;

std.debug.print("--- basic while\n", .{});
while (i < items.len) {
    std.debug.print("index {d}: item {d}\n", .{ i, items[i] });
    i += 1;
}

i = 0;
std.debug.print("--- while with increment expression and continue\n", .{});
while (i < items.len) : (i += 1) {
    // increment expression is calculated as part of continue
    if (i % 2 == 0) continue;
    std.debug.print("index {d}: item {d}\n", .{ i, items[i] });
}

In Go there is no while for looping, but you can achieve it with a for with only the condition. The example with continue could be solved in better ways, but it's presented this way to highlight the disadvantage of not having the separate expression as Zig offers.

// Go
items := [10]int8{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
i := 0

fmt.Println("--- condition-only for loop (while style)")
for i < len(items) {
    fmt.Printf("index %d: item %d\n", i, items[i])
    i += 1
}

i = 0
fmt.Println("--- condition-only for loop (while style) with continue")
for i < len(items) {
    if i == 5 {
        i += 1
        continue
    }
    fmt.Printf("index %d: item %d\n", i, items[i])
    i += 1
}

for loop

As for the for loop, Zig uses it more as a multi-iterator: this means we can pass as many iterable objects as we want to the for loop, as long as they have the same length, or numeric ranges. If we use an open-ended numeric range, the length of the iterable will be used as the end point.

std.debug.print("--- for iterator capturing only values\n", .{});
for (items) |value| {
    std.debug.print("item {d}\n", .{value});
}

std.debug.print("--- for iterator capturing value and index\n", .{});
for (items, 0..) |value, y| {
    std.debug.print("index {d}: item {d}\n", .{ y, value });
}

const letters = [10]u8{ 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j' };
for (items, letters, 10..) |item, letter, index| {
    std.debug.print("index {d}: letter {c} - item {d}\n", .{ index, letter, item });
}

std.debug.print("--- for iterator with range only\n", .{});
for (0..(items.len / 2)) |y| {
    std.debug.print("index {d}: item {d}\n", .{ y, items[y] });
}

In Go it's idiomatic to use for combined with range and extract indices and/or values

fmt.Println("--- classic for loop ")
for i = 0; i < len(items); i++ {
    fmt.Printf("index %d: item %d\n", i, items[i])
}

fmt.Println("--- for loop with range, Go idiomatic ")
for z, item := range items {
    fmt.Printf("index %d: item %d\n", z, item)
}

fmt.Println("--- for loop with range capturing only value")
for _, item := range items {
    fmt.Printf("only item %d\n", item)
}

fmt.Println("--- for loop with range capturing only index")
for z := range items {
    fmt.Printf("only index %d\n", z)
}

Mutating values while looping

In both Zig and Go it's not possible to directly mutate captured values since they are copies. In Zig this is explicit because the captured value is a const, so any modification is blocked at compile time; in Go it's not obvious and must be verified by running the program. Let's see how to handle mutation during the loop in each language.

// declared as var so items can be mutated
var mitems = [10]i8{ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
std.debug.print("--- for iterator with value mutation\n", .{});
// point to array and use pointer to value 
for (&mitems) |*value| {
    // dereference the pointer to mutate value
    value.* *= 2;
}

for (mitems, 0..) |value, y| {
    std.debug.print("index {d}: item doubled {d}\n", .{ y, value });
}

mitems := [10]int8{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
fmt.Println("--- for loop with mutation")
for z := range mitems {
    // use index and not captured value
    mitems[z] *= 2
}

for z, item := range mitems {
    fmt.Printf("index %d: item doubled %d\n", z, item)
}

Zig vs Go: condition flows

Paolo Carraro — Thu, 15 Jan 2026 22:58:34 +0000

(you can find previous post about same topic here)

Comparing the flow control capabilities between Zig and Go reveals how Zig manages to have a more expressive syntax to solve certain specific cases in a clear and elegant way: for example the labeled block returns a value as a constant that is actually calculated using logic and variables from the scope in which it is defined.
It's also worth noting that Zig's switch must always be exhaustive and therefore not leave any unresolved branches.

// Zig
const std = @import("std");
const random = std.Random;

pub fn main() !void {
    const seed = std.time.timestamp();
    var rpcg = random.DefaultPrng.init(@intCast(seed));
    // calc random integer on range 0 - 10
    const rndInt = random.uintLessThan(rpcg.random(), u8, 10);
    // classic if
    if (rndInt < 5) {
        std.debug.print("number is smaller than 5: {d}\n", .{rndInt});
    } else {
        std.debug.print("number is greater than 4: {d}\n", .{rndInt});
    }
    // if inline
    const result = if (rndInt < 5) "smaller than 5" else "greater than 4";
    std.debug.print("{s}\n", .{result});

    // switch with ranges and lists
    switch (rndInt) {
        0...4 => std.debug.print("number is smaller than 5: {d}\n", .{rndInt}),
        5, 10 => std.debug.print("number is divisible by 5: {d}\n", .{rndInt}),
        6...9 => std.debug.print("number is greater than 4: {d}\n", .{rndInt}),
        else => std.debug.print("number is out of range: {d}\n", .{rndInt}),
    }

    // arbitrary logic: demonstrating how to resolve a value using a labeled block
    const calculatedValue: i16 = lb: {
        if (rndInt == 0) {
            break :lb -300;
        }

        if (rndInt == 3) {
            break :lb -900;
        }
        break :lb rndInt * 5;
    };

    std.debug.print("calculated value based on random init with labeled block: {d}", .{calculatedValue});
}

In Go we can solve the same logic in these two ways

// Go
package main

import (
    "fmt"
    "math/rand"
)

func main() {
    rndInt := rand.Intn(10)

    // classic if
    if rndInt < 5 {
        fmt.Printf("number is smaller than 5: %d\n", rndInt)
    } else {
        fmt.Printf("number is greater than 4: %d\n", rndInt)
    }

    // switch with conditional cases
    switch {
    case rndInt < 5:
        fmt.Printf("number is smaller than 5: %d\n", rndInt)
    case rndInt == 5 || rndInt == 10:
        fmt.Printf("number is divisible by 5: %d\n", rndInt)
    case rndInt > 5:
        fmt.Printf("number is greater than 4: %d\n", rndInt)
    default:
        fmt.Printf("number is out of range: %d\n", rndInt)
    }
}

Zig vs Go: constants, variables and basic types

Paolo Carraro — Thu, 15 Jan 2026 00:15:37 +0000

(you can find previous post about same topic here)

const and var

Being two statically and strongly typed languages, there are many similarities in the definition of constants and variables, which must therefore be explicitly typed or typed by inference. Let's see some examples

// Go
func main() {
    const myInt int32 = 123
    // typed by inference
    myFloat := 12.34
    fmt.Printf("integer: %d - float: %f\n", myInt, myFloat)
    myFloat = 45.67
    fmt.Printf("integer: %d - float: %f\n", myInt, myFloat)

    // zero value assigned
    var myBoolean bool
    fmt.Printf("boolean: %t\n", myBoolean)
    myBoolean = true
    fmt.Printf("boolean: %t\n", myBoolean)

    // print types
    fmt.Printf("%T - %T - %T\n", myInt, myFloat, myBoolean)
}

// Zig 
pub fn main() !void {
    const myInt: i32 = 123;
    var myFloat = 12.34;
    myFloat = 45.67;
    // typed by interence
    const myBoolean = true;
    std.debug.print("integer: {d} - float: {d} - boolean: {}\n", .{ myInt, myFloat, myBoolean });
    // print types
    std.debug.print("{} {} {}\n", .{ @TypeOf(myInt), @TypeOf(myFloat), @TypeOf(myBoolean) });

    // no zero value in Zig
    var undefinedValue: f32 = undefined;
    std.debug.print("undefined value: {d}\n", .{undefinedValue});
    undefinedValue = 73.123;
    std.debug.print("assigned value: {d}\n", .{undefinedValue});
}

Zig's ability to initialize to undefined aims to optimize memory management to avoid unnecessary initialization costs and depends on how the executable is compiled. You can get safer behaviors where memory is initialized to default values (in debug mode for example) or optimizations where only memory is allocated but on first read what was previously there is read. It is therefore up to the developer to evaluate what is best in the specific case.

Numeric types

Zig, unlike Go, has the ability to indicate how many bytes should be allocated for an integer or real number: for example, we can specify u2 to indicate a positive integer that contains a maximum of 3. In case of normal additions that overflow the type, we get a panic unless we use a particular syntax for operations (for example %+) to handle overflow with wrap around as Go does by default.

// Go
var myNumber uint8 = 255
fmt.Printf("value : %d\n", myNumber)
myNumber += 1
fmt.Printf("value overflow tollerated : %d\n", myNumber)

// Zig
var myNumber: u2 = 3;
std.debug.print("number {d} of type {}\n", .{ myNumber, @TypeOf(myNumber) });
myNumber += 1; // panic error!

String type?

In Zig, one thing that stands out is that there is no string type, but strings are treated as arrays of bytes (u8) that can also become read-only when we insert a hard-coded string since the string becomes part of the compiled binary.
Furthermore, for compatibility with C, arrays or slices always contain a 0 (null terminator, not the representation of 0) at the end used as a sentinel, that is, as a string delimiter. The difference with Go, which hides this complexity (pointer to a slice and a length), in this case is so marked that it's not worth making much of a comparison.

// hard coded string are a pointer of a read only array
const myConstString: *const [14:0]u8 = "hello ziguanas";
std.debug.print("const string {s}\n", .{myConstString});
std.debug.print("len and size of myConstString: {d} - {d}\n", .{ myConstString.len, @sizeOf(@TypeOf(myConstString.*)) });
std.debug.print("first value of string {d} formatted as char \"{c}\"\n", .{ myConstString[0], myConstString[0] });

// create allocator
var gpa = std.heap.GeneralPurposeAllocator(.{}){};
defer _ = gpa.deinit();
var allocator = gpa.allocator();

// allocate memory for contains the string
var myStringAllocation = try allocator.alloc(u8, myConstString.len);
defer allocator.free(myStringAllocation);
// fill allocation copying a const string
@memcpy(myStringAllocation, myConstString);
std.debug.print("allocated string before edit: {s}\n", .{myStringAllocation});
// mutate the string
myStringAllocation[0] = 'H';
std.debug.print("allocated string after  edit: {s}\n", .{myStringAllocation});

Zig vs Go: init and run

Paolo Carraro — Mon, 12 Jan 2026 23:59:37 +0000

This is the first post about Zig. As a guide for its exploration, I use my knowledge of Go and consequently I will make a comparison between these two languages wherever possible.

Project Setup

In Go we use
go mod init module-name

while in Zig it's just
zig init

In Zig, "module paths" are not specified as in Go because there is no exact correspondence between package import and its URL: this approach seems more flexible but I must also say less standardized.
Zig also proposes a minimal project scaffold to be able to build or run, or even launch unit tests. Unlike Go which only creates go.mod, this seems like a point in favor of Zig.

Main function

// Go
package main

import (
"fmt"
)

func main() {
    fmt.Println("Hell world")
}

// Zig
const std = @import("std");

pub fn main() !void {
    std.debug.print("Hell World", .{});
}

In both languages, main is the reserved function as the entry point for the application. Both don't accept input parameters and arguments passed must be handled with standard library functions. As for the return, Zig is consistent as it treats main like all other functions (error or value, in this case void) while in Go the success return is implicit and the error must be handled inside the function typically with an os.Exit(1) or a panic("error!").

Build and Run

To run our application we have a very similar command between the two languages. In Go we do
go run main.go
while in Zig
zig run src/main.zig

The same goes for a simple build
go build main.go
zig build src/main.zig
Note the creation of a zig-out/bin folder where we will find the generated binary. This folder is a convention but taking a look at build.zig it becomes very clear how the definition of build, run and test is not provided by the tools but is manageable via code using Zig itself as the language!

Mise-En-Place: a quick and easy tool for managing a dev environment

Paolo Carraro — Fri, 21 Nov 2025 14:55:58 +0000

(ITA version)

For a few months now, I've been using Mise En Place as a tool to manage my environments: from macro (entire virtual machine) to micro (single project).

Frustrated by always having to start from scratch when creating a new virtual machine with WSL2, this tool was suggested to me, and I've come to appreciate it more and more for its ease of use, speed, and consistency.

It's the classic "Swiss Army knife" tool that allows you to manage tools and their versions in a specific project or across the entire machine, load a project's environment variables when you enter the project folder, and manage the tasks/scripts you want to use to automate the project itself.

After the quick installation using the script indicated here, you can explore the commands with
mise help
The extensive list of available commands is immediately noticeable. I will limit myself here to commenting on the ones I use most often, which concern tool management.

mise list | ls

This command allows you to see the list of all installed packages, highlighting those that are active and those currently unavailable. This is because some packages might only become active when you enter the folder where the use of that tool in that specific version has been configured. The entire list thus indicates all dependencies installed in the local cache.

mise use | install

use is the command most often invoked to install a tool; let's look at some examples of usage:
mise use -g go
With this command, we install Go at the latest version and make it globally available. The global configuration is available at the path ./config/mise/config.toml.

~/my-projects/project-a/mise use node@19
With this command, we configure the use of version 19 of Nodejs (the most recent minor and patch version of the indicated major will be downloaded). This version of Nodejs will be activated every time we enter the project folder. We will notice that in this case, mise will have created the configuration file mise.toml for us. If mise does not find Nodejs 19 available in the cache when entering the project folder, it will raise a warning. At that point, it will be enough to run the command mise install to download the required dependencies.

The difference between use and install is that use installs and configures, while install downloads the dependency into the cache, thus making it available later if configured via mise.toml.
Note that by having mise ls node show us the list of available Nodejs versions, it clearly indicates the active version, the source that configured it, and what version was requested

Mise allows you to easily try downloading a tool by only indicating its name; it will then resolve this name with one or more backends that implement it.

As you can see, this tool can be resolved with various backends that make it available. Among these backends, we also find well-known package managers like cargo and npm, or languages that offer installation capabilities like Go. Some, like ubi, for example, use releases available on Github.

The counterparts to use and install for removing dependencies are unuse and uninstall.

mise which

This command allows you to see where the binary of the application you are using is located.

This gives us an idea of how mise uses the cache through shims, a system similar to middleware for manipulating the PATH of our shell in this case.

mise outdated

This command creates a report showing the status of every installed tool whose version is not up-to-date compared to the version initially requested, which is 'latest' by default.

mise upgrade

This command handles updating all versions in accordance with the version requested during configuration with use.

mise prune

This command allows you to clean up all dependencies that are no longer used (i.e., not listed in any configuration file). Confirmation is still requested for each one before removal.

mise search <tool-name>

This command allows you to search the mise registry to see if the indicated tool is available so you can then install and use it.

mise helix npm and lsp

Using Helix as my editor, I download several LSPs for managing codebases in various languages. BUT with LSPs distributed via npm, especially in the frontend/html context, my experience with mise has not been optimal, as Helix cannot find them available unless I go and define the path created by mise in the languages.toml configuration file. For now, I have returned to using pnpm as a global package manager.

Did you already know about mise? What has your experience been using it?

Mise-En-Place: un tool veloce e facile per gestire un ambiente di sviluppo.

Paolo Carraro — Fri, 21 Nov 2025 14:46:42 +0000

(ENG version)

Da qualche mese ormai, sto usando Mise En Place come tool per gestire i miei ambienti: dal macro (intera macchina virtuale) al micro (singolo progetto).

Frustrato dal dover sempre re-iniziare daccapo quando creavo una nuova macchina virtuale con WSL2 mi è stato suggerito questo strumento che ho apprezzato sempre di più per la facilità di utilizzo, la velocità e la consistenza.

E’ il classico tool “coltellino svizzero” che ti permette di gestire i tool e le loro versioni in un determinato progetto o nell’intera macchina, caricare le variabili d’ambiente di un progetto quando entri nella cartella del progetto, e i task/script con cui si vuole automatizzare il progetto stesso.

Dopo la veloce installazione con lo script indicato qui si possono esplorare i comandi con

mise help

Si nota subito la nutrita lista di comandi disponibili. Mi limito qui a commentare quelli che uso più spesso e che riguardano la gestione dei tool.

mise list | ls

Questo comando permette di vedere l’elenco di tutti i pacchetti installati, evidenziando quelli che sono attivi e quelli al momento non disponibili: questo perché alcuni si potranno attivare qualora si entra nella cartella dove è stato configurato l’utilizzo di quel tool in quella specifica versione. L’intera lista indica quindi tutte le dipendenze installate nella cache locale.

mise use | install

use è il comando più spesso invocato per installare un tool; vediamo alcuni esempi di utilizzo:

mise use -g go

Con questo comando installiamo Go all’ultima versione e lo rendiamo disponibile globalmente. La configurazione globale è disponibile al path ./config/mise/config.toml

~/my-projects/project-a/mise use node@19

Con questo comando configuriamo l’utilizzo della versione 19 di Nodejs (verrà scaricata la minor e patch più recenti della major indicata). Questa versione di Nodejs si attiverà ogni volta che entriamo nella cartella di progetto. Noteremo che in questo caso mise avrà creato per noi il file di configurazione mise.toml. Se mise non troverà disponibile nella cache Nodejs 19 entrando nella cartella di progetto solleverà un warning. A quel punto basterà lanciare il comando mise install per scaricare le dipendenze richieste.

La differenza tra use e install è che use installa e configura mentre install scarica la dipendenza nella cache e la rende quindi successivamente disponibile qualora la si configuri via mise.toml.

Da notare che facendoci indicare la lista di Nodejs disponibili con mise ls node ci indica chiaramente la versione attiva e la sorgente che l’ha configurata e che versione era stata richiesta

Mise permette di provare a scaricare facilmente un tool indicandone solo il nome: risolverà poi questo nome con uno o più backend che lo implementano.

Come si nota questo tool può essere risolto con vari backend che lo rendono disponibile. Tra questi backend troviamo anche noti package manager come cargo e npm oppure linguaggi che danno la possibilità di installare come go. Alcuni come ubi per esempio utilizzano le release disponibili in Github

I corrispettivi di use e install per rimuovere le dipendenze sono unuse e uninstall

mise which

Questo comando permette di vedere dove è ubicato il binario dell’applicazione che stiamo usando.

Questo ci permette di avere un’idea di come usa la cache mise attraverso gli shims, un sistema simile al middleware per manipolare in questo caso il PATH della nostra shell.

mise outdated

Questo comando crea un report che mostra lo stato di ogni tool installato la quale verisione non è aggiornata rispetto alla versione richiesta inizialmente, che di default è latest.

mise upgrade

Questo comando si occupa di aggiornare tutte le versioni in accordo con la versione richiesta durante la configurazione con use

mise prune

Questo comando permette di ripulire tutte quelle dipendenze che non sono più usate, quindi elencate in qualche file di configurazione. Viene comunque richiesta la conferma per ognuna prima di rimuoverla.

mise search <tool-name>

Questo comando permette di cercare nel registro di mise se è disponibile il tool indicato per poi poterlo installare ed usare.

mise helix npm e lsp

Usando come editor Helix scarico parecchi LSP per la gestione delle codebase nei vari linguaggi. MA con gli LSP distribuiti via npm soprattutto nell’ambito frontend/html la mia esperienza con mise non è stata ottimale in quanto Helix non riesce a trovarli disponibili a meno di andare a definire il path creato da mise nel file di configurazione languages.toml. Per ora sto usando quindi sono tornato ad usare pnpm come gestore globale dei pacchetti.

Conoscevi già mise? Che esperienza hai avuto nell’usarlo?