Zig First Impressions from a JS Dev

Anonymous Duck — Sat, 24 Aug 2024 13:02:59 +0000

I've been learning zig for my game development project, read more about it here. Those are my initial (mostly positive) impressions of the language, coming from a mostly JS/TS recent experience.

Error handling

Errors are values - It's quite a popular opinion at this point that exceptions aren't the best. They create a hidden control flow, and in JavaScript they can't even be declared; which makes your applications much more unstable.

Zig uses error enums and nice syntactical sugar for easy and fun error handling. For example :

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

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

In the code above we declare an error MyError (This can also be done separately) and return it.
The try means "if this returns an error, return it here" as in:

failingFunction() catch |err| return err;

I believe this approach is a great combination and saves us from the endless if (err != nil) in Go land.

Other highlights:

Errors are explicit, all types have to be declared and handled
Handling is done right then and there, not on the block level
Thanks to payload capturing, errors are typed correctly and autocompeleted, making it easy to use something like a switch expression.

The !void syntax - ! is used to create a union between the return type and the error types. Zig supports not adding any errors prior to the !, which is supposed to create a union of all the errors that you actually return from the function.

In practice, I find this syntax unhelpful. At least with my IDE experience I don't get any intellisense in this case, and it makes the function less clear. Just tell me what you are gonna return!
I only see it being useful on the main() function.

Payload capturing

You know how in TS you might have a type like number | undefined? You might use an if or some logic to narrow down the type to what you need, and TS automatically displays the new type correctly.
While it's easy, there are problems with this approach:

If types can change throughout a function, it's harder to follow
In some cases you still have to do a cast

In Zig, you do this with "Payload Capturing". You can "capture" aka create a new immutable variable with the resulting type. For example:

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

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

It's very clear what's happening! Moreover, the variable is immutable, but if you really need to change it, you can capture a pointer to the value instead.

It's also worth mentioning that this mechanism can be used throughout the language, including: for, switch, catch, etc.

Comptime shenanigans

Admittedly I didn't yet grasp the full possibilities of comptime. But in short, you can run regular code during compilation. You may create whole functions that are only used during this time, and can return compilation errors if necessary.

It suits Zig quite well, because it's a very malleable language. Even types are values, meaning you can create, change, and get information about types (Especially in comptime).

A basic example of this from the Zig Guide:

const a = 5; // When a number type isn't specified, it defaults to comptime_int
const b: if (a < 10) f32 else i32 = 5;
// b: f32 after compilation

Editor experience

I'm using VSCode with the official Zig plugin (which uses zls). The intellisense and errors I see in the editor leave much to be desired.

"detectable illegal behavior" aka illegal things that will result in a compilation error aren't typically displayed in the editor. For example:

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

I'm on the 0.14 (dev) master branch version, if it's supposed to work let me know in the comments!

EDIT:
I was able to enable this type of error checking in VSCode by enabling the "Enable Build On Save" option under the zig extension settings.
Which is exactly what it sounds like, saving the file will rebuild the app and show any errors resulting from compilation on the correct lines. 🤦

Un-frameworking myself

Anonymous Duck — Tue, 20 Aug 2024 10:28:25 +0000

Recently my Youtube feed has been filled with videos talking about how "people rely too much on frameworks" or "devs don't really know how things work anymore" etc. And it has gotten me thinking, are we (especially web developers) just monkeys learning to connect one super abstract tool with another to fit our use-case? Seemingly throwing existing libraries and solutions at the problem until one sticks?

Maybe.

Background

I'm a gen z developer, I started programming from Java and C, and only in my first "real" job I began using JavaScript seriously. Because of that, I felt a bit "superior" to my fellow junior devs, as if knowing what is a pointer was the same thing as writing your own compiler or OS.

And yet, having worked pretty much exclusively with JS/TS for the past 2.5 years, I feel like my brain has rotten. Any new project I make uses TS by default, with tons of cool and shiny libraries and tools piled on top.

Because you can't just use node, you gotta use Bun! and maybe elysia for the api, connected to EdgeDB; Perhaps NextJS for the website, with additional dependencies like React Query, Redux, Tailwind and so on. Then you might use something like Turborepo or NX to put everything in a monorepo...

When me and our company's architect were arguing about this topic, he actually said:

In every case, ever, if there is a library for it, we should use it.

I feel like this is just insane...
Sure, existing libraries have already been written, and they are more standard, maintainable*, and so on. And in many cases I agree, we shouldn't re-invent the wheel, especially when it comes to standards.

But using all those tools often eventually leads to:

Worse performance
INCREASED complexity
Lower security and overall lowers developer satisfaction and skill. (Not to mention that we're still stuck on Material UI 4 with no prospects of upgrading)

Don't get me wrong, I'm not advocating for inventing your own standards, or (god forbid) using XML. I just feel like doing away with some of our libraries or even excluding big extensive frameworks, could bring really nice benefits to many companies and solo devs.

My Plan

I want to do something stupid, I want to undergo a "trial by fire" of sorts to purge my brain, and train my hands to build complex things without relying on code I don't know or don't understand.

Making a game from scratch

I figured that making a game engine (from as much scratch as I can manage) is a pretty stupid idea. Many have already said that:

If you want to make a game - do not make an engine

I figure building an engine is a complex thing, that actually necessitates using a low-level language like C/C++ or Zig. Which will give me plenty of opportunity to suffer, and implement basic things, very terribly, just to prove that I can (...or can't).

So that's the plan, build a 2/2.5D game (currently in Zig) while using as little dependencies as I possibly can, and share the process with you guys ❤️.

Signs that things are getting better

Despite the mess that most JS/TS startups and developers find themselves in today, I feel like many are realizing it, and the industry is moving in the right direction. More and more companies are switching to greener pastures like Go and Rust. While frameworks are moving things to the backend and trying to simplify your infrastructure.

But I feel like as long as people keep using JavaScript (and they will), our dependency trees will continue growing and flourishing.

Because when all you know is JS, everything looks like a JS problem.

DEV Community: Anonymous Duck