Lemmy.World

170,748 readers
8,284 users here now

The World's Internet Frontpage Lemmy.World is a general-purpose Lemmy instance of various topics, for the entire world to use.

Be polite and follow the rules ⚖ https://legal.lemmy.world/tos

Get started

See the Getting Started Guide

Donations 💗

If you would like to make a donation to support the cost of running this platform, please do so at the following donation URLs.

If you can, please use / switch to Ko-Fi, it has the lowest fees for us

Ko-Fi (Donate)

Bunq (Donate)

Open Collective backers and sponsors

Patreon

Liberapay patrons

GitHub Sponsors

Join the team 😎

Check out our team page to join

Questions / Issues

More Lemmy.World

Follow us for server news 🐘

Mastodon Follow

Chat 🗨

Discord

Matrix

Alternative UIs

Monitoring / Stats 🌐

Service Status 🔥

https://status.lemmy.world

Mozilla HTTP Observatory Grade

Lemmy.World is part of the FediHosting Foundation

founded 2 years ago
ADMINS
1
 
 
2
-2
submitted 1 week ago* (last edited 1 week ago) by erlend_sh to c/[email protected]
 
 

There are endless debates online about Rust vs. Zig, this post explores a side of the argument I don't think is mentioned enough.

Intro / TLDR

I was intrigued to learn that the Roc language rewrote their standard library from Rust to Zig. What made Zig the better option?

They wrote that they were using a lot of unsafe Rust and it was getting in their way. They also mentioned that Zig had “more tools for working in a memory-unsafe environment, such as reporting memory leaks in tests”, making the overall process much better.

So is Zig a better alternative to writing unsafe Rust?

I wanted to test this myself and see how hard unsafe Rust would be by building a project that required a substantial amount of unsafe code.

Then I would re-write the project in Zig to see if would be easier/better.

After I finished both versions, I found that the Zig implementation was safer, faster, and easier to write. I’ll share a bit about building both and what I learned.

view more: next ›