I’m planning use Gleam + zig in my server, is stupid?
Gleam have powerfull tools to handle with crash and recover. But Gleam is a language that’s too simple for what I want. I don’t want to be forced to follow the simplistic paradigm of the language throughout the entire architecture, so I thought about using a shared library to bridge the two: Gleam would receive the requests and handle the high-level stuff, while Zig would handle the actual business logic.
Zig has comptime, very compelling data structures, better control over structure, error handling, and things like that. Performance isn’t really my main concern for now — it’s the architecture and structure.
I haven’t found another language that gives me what Zig does in terms of structure, error handling, and so on. Basically, Gleam would handle authentication, headers, validation, timeouts, etc., while Zig would handle the business rules and data structures in general.
Is this completely stupid, or does it actually make some sense? As long as the performance doesn’t degrade to the point where it’s basically as slow as a Node server, that would already be enough for me.
I cant speak for gleam because I have never used it, but you will have to communicate with C ABI between the two different languages. That in itself is not going to introduce a performance problem but you will need to sync every data structure and function signature* as well. If you think managing this is worth it, it makes sense.
EDIT: Basically anything that needs to be interactive between the languages needs to be in C ABI. There are multiple ways to do this, none of them is pretty imo. The parts that dont need this interactivity(is this the right word? idk) can be just “pure zig/gleam”.
It’s not a bad plan .. gleam sits on top of Erlang, which has a very robust and battle tested set of tools for running network servers with predictable low latency, and fault tolerance.
To hook zig into this, you have 2 paths ..
Is to load zig code as a NIF, so it executes in the same process as the gleam code. Several downsides to this - you need to be super careful about hogging the cpu (you need to implement yield points at regular intervals), and any crash can take down the server. https://github.com/E-xyza/zigler is a good setup to integrate zig with anything running on the beam. It will work with gleam.
Other option is to run your zig code as a separate process, that consumes messages from your beam app, and returns messages. These zig processes can be supervised by the beam (the gleam app will fire up the zig process, monitor it, restart on crash, etc). It’s very cool, because you can spin up zig processes on different machines across the network, and clustering is automatic and free. Who needs Kubernetes? See https://github.com/zigster64/beam.zig for a complete example of how to do this.
Gleam, elixir, and half a dozen other languages are pretty cool - but they all end up producing byte code that runs on the beam. If you use any of them, it pays to have a basic understanding of Erlang anyway. Don’t be scared to mix and match, and don’t be scared to write a bit of Erlang either. It’s weird, but in a good way.
Thank you very much for the instructions! But now I have a question in mind: couldn’t I directly use Zig’s shared library format to connect us? I was planning to have three connections: “onRequest” (with the response being its return value), “onStart”, and “onAbort”.
Well, anything is possible, so you could use Zig shared library code, but that’s going well against the architecture and would require an inordinate amount of hacking. Interesting .. worth trying even, but you are up for a lot of work. Try it and see how you go.
Personally - I would reach for doing the Zig part as a c-node, and go for a design that uses mailboxes to pass messages around instead. That’s the default architecture for anything on the BEAM, and it’s what gives you all the free goodies like distributed processing and fault isolation.
I don’t mind if you want - brain dump what you are trying to build, and can rubber duck some plans of attack ?
