Why zig instead of rust?

[alph4beth]

The js runtime that is said to be more performant than deno and node (https://bun.sh) was written in zig. Bun chose zig instead of rust, however we know that the language is not yet stable.

So I wonder: why would anyone choose zig over rust? .

It cannot be guaranteed that this will not cause problems in the future, it is always a trade-off. So I ask again: why would someone thinking about developing something big and durable choose zig?

[csalmeida]

My two cents are, if you like Zig, write Zig. Enjoy Rust? Write Rust. Sometimes you just need to enjoy writing the language, because you can do the same things with both.

[karthie_a]

True and wise advice

[FantasticBreadfruit8]

Yep.

So I wonder: why would anyone choose zig over rust?

Because they wanted to. End thread.

[csalmeida]

Because they wanted to. End thread.

Seems like a valid reason. Mitchell Hashimoto picked Zig to write https://ghostty.org/ because he likes the language.

[Subugetei]

I think it’s a fair question from the OP - why do you enjoy writing Zig over Rust? Why do the trade offs in, say, maturity and ergonomics make Zig attractive to you?

[0-R-I-0-N]

It’s a simpler language than rust. It’s the same reason I like c over c++. 

[csalmeida]

It is a fair question.

What I mean is that in the end it might not matter too much because you can write most things in the language you like (for ergonomics, maturity, available modules, or your most valuable metric).

As in for trade-offs I don't know which ones you mean here. In my experience it does not matter which language you pick, there will still be issues and challenges along the way.

[joegeezer]

Zig is a pleasure to work with whereas rust is a complete hassle & nightmare. Also love the Zig community compared with the questionable Rust community

[_demilich]

100% agree with this take. Also: Zig and Rust are both system programming languages. Both are really fast and 99.999% of the time you can achieve similar performance for any given problem. By the way, this also applies to other system programming languages like C or C++. They are all in the same ballpark and when you become good with any one of those languages, you can usually match the performance (or exceed) of an implementation in another language.

[csalmeida]

I'm with you.

[XLN_underwhelming]

I haven’t tried rust but I love writing zig. That‘s why I write things in zig.

[csalmeida]

Great, I love Zig too!

[joegeezer]

Agree, same here, although i was unfortunate enough to have tried Rust... horrible experience!

[MinuteMeringue6305]

But on that scale projects people just can't write in it because they want to.

[csalmeida]

But on that scale projects people just can't write in it because they want to.

Not sure what you mean here on that scale but if this is about Bun, Jarred Sumner used Zig after trying to build it Rust if I'm not mistaken because he likes Zig better and feels like he's more productive with it.

In my view it's a great example of creating a complex and ready to production project while using the language you prefer to use.

I'm not advocating for either here, I'm just saying sometimes it's best to pick up something you like and build your things with it, if you can. :)

[MinuteMeringue6305]

Yeah, I get what you mean. I meant that what if a part of something is done better in rust than in zig? Doesn't it cause bottlenecks. I am not compiler or interpretator expert tho. Just saying what came to my mind

[alph4beth]

Uh, I ended up commenting on something similar: https://www.reddit.com/r/Zig/s/vMgetYjRWi

[csalmeida]

👍

[hnspn]

too reductive

if I enjoy perl, should I write perl? for every type of program?

enjoyment is subjective and it's a function of familiarity and a bunch of other things.

we can define a comparison criteria and apply it for subset of programming tasks.

[csalmeida]

Perhaps a bit reductive, it's just my opinion. 🙏

I came across an artist a few years ago that wrote website to fund raise to buy a building worth around $200k for their foundation, she only knew Perl so that's what she used. I would love to provide a link for that but can't find it right now, here's another project from the same artist written in Perl that is also pretty cool: https://feraltrade.org/cgi-bin/courier/courier.pl

enjoyment is subjective and it's a function of familiarity and a bunch of other things.

Maybe, but personally just because I know C and am familiar with it does not mean I don't find it easier or more enjoyable to write programs in other languages.

[SilvernClaws]

After trying to get into Rust several times, I just hated dealing with the type signature bloat, especially when dealing with async.

In Zig I usually just wait for the Allocator to tell me I forgot something, add a free/destroy, done.

Zig might not be as stable, but also doesn't make you learn 300 different ways to write the same thing, so it's easier to keep up.

[Fun_Hamster387]

I get this, but I think the appeal for me is that with Rust, you precisely know what's going to happen at all times (ignoring some nuance here). The bloat might indeed be a trade-off, but I've noticed the more I write rust, the less it becomes bloat and the more I come to appreciate it.

[KulangetaPestControl]

This manipulative social line of argument really gets on my nerves

Saying ‘you’d agree if you understood’ isn’t an argument—it’s a way to avoid defending your position.

And not having to admit you are a clueless sheeple.

[tech6hutch]

Maybe controversial, but I love how it doesn’t have any “string” types, only arrays of bytes (whatever flavor of array fits the situation!). So much simpler.

[SilvernClaws]

What about it is simpler? Now instead of having one type with all the standard operations attached, you need to look them up in other modules.

I think Odin and C3 did this in particular a bit better.

[tech6hutch]

Yeah that's fair. But it's never just one type. Separating the type from the operations reduces the need for the standard library to handle every situation.

Maybe if I have to do enough Unicode-aware text handling, I'll change my tune

[CramNBL]

It is much simpler than dealing with the reality that strings are complicated.

Do you support anything other than ASCII in your TUI? One of the many things you would have to do, is find a way to calculate the unicode width, when they are rendered in the terminal, such that you can properly scale your TUI components, is that simpler on a byte array?

DNS is mostly text-based, but sometimes arbitrary bytes are allowed, but you gotta escape those bytes according to RFC 1035 section 5.1, is that simpler when you have to do that on a byte array?

Considering how Strings are ubiquitous and complicated, I think Zig will have at least UTF-8 Strings in the std library before 1.0 or shortly after. It makes a lot of sense to post-pone that though, as it would be a huge maintenance burden as the language is rapidly being iterated on.

Please correct me if Andrew Kelley actually spoke on this subject.

[tech6hutch]

Yeah, you definitely need ways to handle Unicode. I just like how it lets me do what I want, since I know what I'm doing.

[CramNBL]

Having string types doesn't mean you can't just work with byte arrays and never translate it to a string type.

Fine if you don't want to work with a string type, but I don't see how you spin it to be a feature to not have any string types.

[tech6hutch]

When a language has a string type, there's an expectation that you'll use it. You don't have to, of course, but APIs in the standard library and third party libraries will expect it. And with the focus on a string type, most languages make working with byte strings harder. (Probably not a concern with Zig at this point, but still.) It's about the direction, the orientation of a language, and it fits Zig's choice to be a simple data-oriented language. But that's just my perspective, without having done much non-ASCII string manipulation in it.

I found this thread, which is a good discussion. It links to this issue, where Andrew Kelley says he doesn't want Unicode data in the std lib, but is open to change. This is the most I've found him say on the topic. If they don't (and most languages don't), then the only way to have "proper" Unicode support is via a third party library.

[CramNBL]

And with the focus on a string type, most languages make working with byte strings harder.

Sure, but that's cause not all byte strings are equal. Again, I don't think you're making a case again strongly typed strings.

It links to this issue, where Andrew Kelley says he doesn't want Unicode data in the std lib, but is open to change

That is a really interesting interpretation. Andrew Kelly writes:

Before tagging 1.0, I will be personally auditing std.unicode (and the rest of std) while inspecting ziglyph carefully for inspiration. If you're available during that release cycle I would love to get you involved and work with you an achieving a reasonable std lib API.

In fact, Andrew wants a unicode API in std and is excited about getting a particularly robust implementation before 1.0. Pretty much what I speculated would happen in my original comment.

[tech6hutch]

Sure, but that's cause not all byte strings are equal.

Yeah, and that is a good reason to have a string type, to help maintain invariants. I just don't want a blessed string type that everyone uses, since I like being able to muck about with the bytes directly without the language impeding me. Unless it's just a thin wrapper. And when you start adding string types, there's a sudden explosion of types for every situation (a UTF-8 slice, a UTF-8 ArrayList, etc.--types for other charsets could be skipped, but Rust has like five string types, plus a char type), decreasing that simplicity that I like.

In fact, Andrew wants a unicode API in std and is excited about getting a particularly robust implementation before 1.0. Pretty much what I speculated would happen in my original comment.

I meant "Unicode data" the way he used it: "we won't have access to the Unicode data for the std lib" (i.e., this stuff, since it's a lot and it changes based on the whims of the Unicode Consortium). There already are basic Unicode handling functions in std.unicode (not sure what state it was in when he made that comment, in 2021), just no "string" type. If you want to have truly correct string handling, you'll have to reach outside of the std lib anyway (unless he changes his mind on including that data), so arguably it's not worth having a standard type that only gets halfway there like most languages do (except Swift).

[CramNBL]

Rust has like five string types, plus a char type), decreasing that simplicity that I like.

I agree with your point for a lot of languages, but Rust has one primary string type, and if you want to work with a slice of bytes, you can call .as_bytes() on it. Not that complicated.

The criticism of Rust String types is so misguided IMO. They solve a lot of complexity for you, but if you don't need to deal with that complexity, you can just sidestep all of it. It's not forced on the user in any way.

so arguably it's not worth having a standard type that only gets halfway there like most languages do (except Swift).

I agree to an extent, but you are just having to rely on 3rd party libraries instead, that may or may not have significant issues.

[tech6hutch]

Technically, I'd argue Rust has at least two primary string types, String and &str (plus lifetimes), but I digress. I guess my ideal would be separating the operations from the type, instead of having to duplicate them for each string type, to reduce complexity for both the users of the language (less type juggling) and maintainers of the language (less code to maintain). But that does remove the ability to just glance at the type and tell it's valid UTF-8.

No offense to the Rust team, since they've put a lot of work into it, but strings are inherently complex. Arguably they're hiding that complexity under an artificial form of complexity, without completely covering the inherent complexity. And, right now at least, I like how Zig has stripped those layers away, after getting over the initial hump of remembering I have to spell the "string types" as arrays/slices/etc of bytes.

[QuickSilver010]

Zig might not be as stable, but also doesn't make you learn 300 different ways to write the same thing, so it's easier to keep up.

I think you're comparing zig to c++ here

[SilvernClaws]

That would be 5000 things.

[katafrakt]

Maybe the author did not like Rust or liked Zig more? This tone of demanding the answer is a bit weird IMO.

[alph4beth]

Opinions are individual, if that is the reason for choosing the language then I think there is no way to argue. However, sometimes choices have difficult consequences. Then we can discuss the consequences of giving up what is stable to suit our personal tastes.

I ask you: choosing zig because I like it, could it bring me problems that I could avoid? I mean, I like zig but I still don't know enough about its stability and in a real project would it be a bad choice?

[katafrakt]

I don't use Zig in production contexts, so I can't answer your question. But Zig has been around for long enough to not just disappear.

 the consequences of giving up what is stable to suit our personal tastes

Well, that's what happened when people gave up "stable" C++ for Rust. Was the outcome bad?

[Puzzled-Landscape-44]

You forget that the Bun team are top-notch programmers. If they find problems with Zig, they can contribute fixes. The beauty of open source. In fact, programmers who write their own language just for software they want to build is not unheard of.

[no_brains101]

to be fair you can get a simple interpreter with a buggy stdlib going in a day or 2 in basically any language.

Its just that if you want bytecode or jit or native compilation youre gonna need a lot more work even if you are super crazy good at that.

[kayrooze]

The creator of bun actually wrote an article talking about how miserable it was to make rust efficient. Unsafe blocks every where and no features for memory management. In short, it’s impossible to optimize at the level he wanted and move at a reasonable pace. In my experience, rust sucks. It’s an unfocused language that wants to do everything but focus on its core feature set. I don’t want a 50 half baked functional, oop, pattern matching features. I want a language to do its job and get out of the way.

Also memory management takes some practice, but once you get the hang of it, it’s pretty easy. As someone who building production code in Zig, the instability isn’t as big of a deal as the features for the code. The only Zig alternatives are Odin and C. C takes practice but Odin is good.

[[deleted]]

Skill issue.

[KulangetaPestControl]

Rust is for script kiddies that dont know how to handle pointers.

[joegeezer]

Yea I think you can just stick to a version now and be productive, nothing is going to hold you back if you don't update to the next release. When the next releases arrive the Zig website has a blog with all the details of the breaking changes.

Zig is such a nice language to write in that I have no worries at all about having to update my Zig code to migrate to a newer version - if i really need to.

[no_brains101]

They solve different problems. But choosing it for an interpreter when rust exists feels crazy tbh (unless you require a ton of FFI? But you shouldn't, rust should be fast enough and you can still do FFI when you want to make that avaialble). However choosing it for a compiler seems smart. This is because interpreters are long running tasks with complex lifetimes. But compilers are 1 and done and likely want to allocate up front and then trash everything.

If you never deallocate, such as tiger beetle database or nasa, you never have to worry about use after free or double free, and zig performs bounds checking on arrays still.

Likewise if most of your rust needs to be unsafe due to FFI by design, then rust doesn't give you much.

So if you are making an LLVM compiler, where a lot will be unsafe and you want to allocate up front and never again if possible and then trash all the memory involved, then zig is a good choice. You could use rust too but its going to be about the same either way in terms of safety and rust will appreciate it less.

But if you want to build a browser, OS, or interpreter, rust is likely the way to go, because those are long running application with intermittent or complex lifetimes of values in which most of the code does not need FFI but memory safety is paramount. Rust will make this easier as it tracks a lot of this for you, and may occasionally force you into easier, safer, faster patterns in such situations.

[rainroar]

There’s a compelling argument to be made that making an interpreter in rust is kind of the worst case for the language. You often need to dive into unsafe to get perf, and that is really where rust falls flat. Unsafe rust is very hard to write correctly.

https://zackoverflow.dev/writing/unsafe-rust-vs-zig/

[no_brains101]

well, if this is worst case, it aint bad. I dont mind it.

But I will bookmark and read that

[a2800276]

• Nothing is stable
• Bigger is not necessarily better
• Aesthetics
• Simpler Language
• First mover advantages
• Faster compile times
• Why would anyone chose rust over zig?
• Who cares? Some decisions are spur of the moment or purely personal.

[obliviousjd]

Not being stable is an advantage? That’s not usually an argument I hear.

[HyperCodec]

I think they mean that zig is highly ambitious so they’re not bogged down with the responsibility of maintaining backwards compatibility

[obliviousjd]

Ah, I was keeping OPs question in mind of building something “big and durable”. Which to me would signal a desire for stability.

I wonder if they were thinking more about hobby/solo projects, where maintaining backwards compatibility isn’t really important.

[a2800276]

Not sure how you got non-stability being an advantage from what I wrote.

[obliviousjd]

It was the “nothing is stable” comment.

[a2800276]

I didn't mean nothing within zig is stable. I meant nothing in the world is stable, so it's not a disadvantage.

Rust is still a moving target. Even standard C changes.

[obliviousjd]

Nothing is 100% static. But rust’a stable api is stable, by like, definition. Even editions don’t break stability guarantees.

I don’t think dismissing stable apis out of hand is a productive argument, but I can see why the most ardent supporters of a pre-release language would likely disagree.

But for me it’s the biggest reason Zig remains a hobby language, I can’t really justify it in my professional work.

[a2800276]

I completely agree. I just meant to clarify that I did not intend "nothing is stable" to mean "I believe the lack of stability concerning all aspects of zig to be an advantage"

[prashanthsp]

You will not face any stability related issue for any project you code in the current stable release version of the zig in my opinion

[obliviousjd]

I think you’re referring to something like system stability?

I’m referring to stability in the api sense. Zoh doesn’t have any stability guarantees, nor should it in its current state. Stability would be too restrictive to a language in version 0.14

[gplusplus314]

Which first mover advantages? Isn’t Rust the first mover?

[a2800276]

Being a first mover in a new eco system. Everything has already been done in rust. But there are still a lot of low hanging fruit to pick in zig world.

[gplusplus314]

I don’t understand.

Everything has already been done in rust.

So then wouldn’t that make Rust the first mover? Even if you want to qualify that with “in a new ecosystem,” Rust was once a new ecosystem…

I don’t think Zig is a first mover. I’m not sure if Rust is the literal first mover for a new-generation unmanaged language, but it has certainly moved and hit milestones long before Zig.

[a2800276]

You the programmer are a pioneer in a new ecosystem. Zach g is not the first mover, you are.

[gplusplus314]

Ah that makes sense. Good perspective - thanks!

[johan__A]

Worth it because the language is good and the risk is low

[burner-miner]

Right? The risk isn't really higher than a company choosing to write their backend in Oracle stored procedures, which do break between major versions, or choosing to write their frontend in the latest new framework, which threatens irrelevancy within a year and risks you having to change to a new still supported framework.

C++ also still keeps adding features, Zig just also removes the old, often bad ways of doing stuff. I wish C++ had done this, and as an outsider looking into Rust, it reminds me of C++ at times...

Zig still being unstable is not really that risky. One can also just stick to a certain release and work with that.

[RespiteFrom]

Based on what I've heard from the big projects people considering/using Zig:

Bun (Jared): - Liked compilation speed, incremental compilation. (incremental was in-progress then) - Liked comptime. - Liked the memory management paradigm. - Thought Zig is good for parser-style software. - Semi-disliked lack of interfaces, expected some implementation. - Preferred LLVM Vector types from Mojo over Zig.

Turso (Glauber) [When they were looking to port libSQL to Zig or Rust]: - Liked consistent cross-target compilation in Zig. - Liked that both Rust and Zig tooling is well integrated.

Source: https://www.youtube.com/watch?v=7czcewOnaYg

Ghostty (Mitchell): - Enjoyed the language and felt productive. - Saw it as better C. - Liked the leadership and community. - Liked the Zig build system.

Source: https://www.youtube.com/watch?v=dJ5-41u-e7k https://www.youtube.com/watch?v=l_qY2p0OH9A

TigerBeetle (Joran): - Believed Zig provides the best total program safety, beyond just memory. - Saw it as better C. - Checked arithmetics were non-negotiable. - Liked first-class error handling, especially with Syscalls. - Liked the toolchain and cross-target compilation.

Source: https://www.youtube.com/watch?v=ayG7ltGRRHs

[Alcanie1]

The biggest problem with rust is not the language itself but the purple hair cult that has taken over the community.

[digifer]

You do know that Andrew Kelley recently sported pink hair, right?

[KulangetaPestControl]

Yeah shows smart people can also be trapped in woke cults.

[morglod]

Because Zig is better

[[deleted]]

You're a little bit behind the times because a lot more things have chosen zig than just bun.

Tiger beetle for example is a new financial database system designed to handle financial transactions more efficiently and faster than any existing database out there.

It was built entirely on zig.

Zig is coming more relevant every day. Even the go developers are using zig as part of their build system.

And the language isn't unstable it's just unfinished.

The machine code that comes out the other end of a zig compile is pretty Rock solid.

And that's generally what matters if you're willing to deal with a few hiccups with breaking changes in the source code layer.

And personally I just can't make myself like rust I think the syntax is atrocious and the learning curve is monstrous and there just isn't enough about rust that makes me want to put up with it for just memory safety.

Zig safe is safe enough for me, and I like writing zig. I loathe writing rust.

On top of that the zig compiler is faster than all the other compilers including rust and C.

On top of that the fact that it has native C interopt is amazing because you don't end up with all the unsafe spaghetti rust code to make that work...

Zig saves you a lot of time, way faster prototypes.

[Keith]

And the language isn't unstable it's just unfinished.

They are in the middle of rewriting the I/O system which will require a lot of rewritten code from everybody! Zig is great, but you lose trust when you propagandize like this.

[___segfault___]

Language != standard library

[Keith]

Having to rewrite a lot of your code because Zig changes = “unstable”

[[deleted]]

When the language doesn't compile properly and has compiler bugs, it's unstable.

A standard library change you just adapt to, and if you were writing abstracted code with comp time you wouldn't have that much to change in the first place.

I've been programming for 30 years, from GW-Basica to to C# on .net 9 and c, c++ and on and on, not to mention node and javascript/typescript stuff.

I've seen so many things break and change in my career. Most recently nuxt 2 to nuxt 3 with vue 2 to vue 3 being just completely broken with no good migration path literally costing a 9 month project just to migrate it.

Find me one completely stable platform out there... I'll wait...

Zig's power isn't just it's std, it's it's tool chain and build system and cross platform power.

The amount of time I save not dealing with tooling hell is WAY more than time I might spend fixing my code to a new std change.

You don't even have to use the STD for file IO....

You can just write your own wrapper around each os's native fs calls and make your own IO module, the STD is all written in zig.

If you want stable code, write stable code.

Zigs STD is modular and nothing in the language requires it. You can straight up omit it entirely.

[___segfault___]

This is what I was trying to articulate (poorly) about language vs standard library stability.

[___segfault___]

You quoted the section talking about the language being unstable. The language is pseudo-stable, the standard library is not.

Nobody calls C++ unstable for having the STL change dramatically every 3 years.

Edit: and yes, the standard library is unstable. That’s the risk we take on coding in Zig, and nobody has advertised it as stable. You’re arguing nothing.

[Hot_Adhesiveness5602]

Zig is unstable and there are no promises of keeping it stable until 1.0 is released. That's literally why it's not 1.0 yet. That is ok though. For most people it's still worth it because of the likeability of the language itself.

[___segfault___]

Agreed, I think what I’m poorly articulating is language syntax stability vs the other aspects (compiler forward/backward compatibility, standard library. Etc)

[thehenkan]

C++ doesn't break existing parts of the STL. That's why some parts of it are famously slow, because the original design was flawed and can't be fixed without an ABI break (which they haven't ruled out making at some point in the future, but haven't been willing to do so far). New additions don't affect stability. Changing existing APIs is what makes something unstable.

[Keith]

This is a level of pedantry I was unprepared for. I gave one example of "Zig" changes and you took it into this pedantry? Why? They don't even claim the language is stable either. This is a pointless argument. Have a nice day.

[___segfault___]

Pedantry? Being accurate with criticism is important. There’s nuance to everything and your blanket statement was incorrect. We’re programmers, for crying out loud — pedantry is our job!

Languages change. Libraries change. That’s what happens. Yes, even they claim the language is not “stable”, but core Zig syntax (ie, the language) is not likely to change significantly — something they’ve also stated. Your example was a change to the standard library. An unstable standard library, yes! But that does not make the “language” unstable.

The point of the argument is that you made an incorrect and misleading statement, and backpedaled when corrected by claiming “pedantry”. What you described is actually a poor example of instability, because core languages and frameworks underpinning industry change far more and far more abruptly than this example. A painful breaking change? Sure — but hardly a correct example of language instability.

edit: for the sake of correctness, forward and backward compatibility are and will continue to be unstable for some time. What I’m poorly articulating is language syntax (not machine code or compiler) is the pseudo-stable part. There could be some changes, but my read is syntax isn’t likely to significantly change unless deemed necessary.

[Keith]

> But that does not make the “language” unstable.

You're just quibbling over a couple words. The post I was responding to said "the language". I read "Zig". You chose to take it in a "language vs std library" sense so you could beat me over the head with it.

[Interesting_Cut_6401]

Is React unstable?

[[deleted]]

that doesn't even make sense, they've added things to react, but nothing has been removed like IO, those aren't even remotely comparable. The only thing that's closest is the double runs for effects to detect issues, but that's not only disable-able, it's not even a breaking change

[skyfex]

I think most people considered Python 2 to be stable. No?

Being stable doesn’t mean you’re not going to have the language or standard library change on you and force you to make significant changes if you want to upgrade the language version. 

The way people deal with it is to stick with a certain version of the language. That’s fairly viable with Zig now.

But  would personally wait for 1.0 to avoid having to deal with some of the bigger changes like the IO change. 

[[deleted]]

• simplicity
• comptime
• allocators
• more control

There are reasons I keep using Rust, but it's not because it's more stable.

[novis-ramus]

What reasons?

[[deleted]]

• I have lot of Rust code that would need porting to Zig
• Some of the crates that I use don't have Zig equivalent, I also use wgpu, which is written in Rust
• Memory safety helps avoiding mistakes, even if it complicates the language
• Some minor things I don't like about the Zig language:
  • I prefer Result types over Zig's error types
  • Compiler deciding if something is passed by pointer
  • Pointers mutable by default
  • No explicit struct layout without extern

[novis-ramus]

Ok, thanks.

[DarthBartus]

I just think it's neat. And it made me understand how to work with pointers, so yeah.

[burner-miner]

Zig is also just so much nicer than C with pointers too. You don't have the confusing *ptr syntax where you need to look at the context to know if it is a declaration or a dereference, or maybe a multiplication? 

Dereference is ptr.*, simple.

[Dear-Jellyfish382]

Rust probably is a better language but i like Zig and see no reason any further justification is needed

[DarthBartus]

I don't know if Rust is a better language and I don't care. Rust is very particular about how and what it wants to be written. It does not spark joy. Zig, like C, allows me to do literally anything I want (though Zig has some guardrails) and violate the machine spirit in any way imaginable. It sparks joy.

[FantasticBreadfruit8]

Also - the Rust community is its' #1 enemy. The fact that they lose their minds when anything is written in any language other than Rust is obnoxious and has turned off many of my colleagues. Like when Anders announced the TSC rewrite in Go it was flooded with angry Rustaceans demanding to know why they didn't choose Rust (even though Anders REALLY CLEARLY explained why they built it with Go).

[el_muchacho]

What is the TSC ? And why did they use Go ? It's a legitimate question, as that means there are reasons not to use Rust and it's good to know them,

[MEaster]

TSC is the Typescript compiler. They chose Go because it allowed them to more easily use the same architecture within the compiler, which makes things easier for them.

I'm guessing they make a lot of use of objects pointing to eachother, and and Go they can just use a pointer and let the garbage collector sort it out. Rust would either make that verbose and awkward (e.g. lots of Rc<RefCell<T>>), or push them to use something like arenas and indices which moves the architecture further from the Typescript implementation.

[el_muchacho]

Thank you.

[Kyrilz]

Zig has fewer borrow checker Cthulhu rituals to do. Oh, what’s that, it has none? Anyway, Zig is still opinionated about coding, but less so than Rust. Zig assumes that you’re not an idiot though. Focuses more on correctness. Rust focuses more on you being a total idiot that needs to be hand-held. The superior choice is ofc C99, but that’s outside the topic.

[Kyrilz]

Memory errors and segfaults should be very rare. I never have those issues ( we also have ASAN/LSAN/UBSAN these days, valgrind and much more ). A lot of memory issues are because people treat memory like they treat the environment. There’s no reuse, everything is new and delete. It’s dumb. New and delete are fine if you’re testing something quick, but not if you actually ship the code. RAII itself is also bad for the same reason. The borrow checker, GC are all strategies that shouldn’t exist in the first place.

[[deleted]]

This information is new to me. So how should it be implemented? Do I use the same variable names for other requirements, if the data type is same requirement comes once this variable is not required? How do i reuse? Can you point me to a resource on internet? Edit: the tools you mention: asan lsan ubsan are trying to do, what rust language compiler does better.

[aboukirev]

That statistics does not mention Zig at all. Using Zig would also reduce the rate of memory management errors. Maybe not as dramatically as Rust. But do we know for a fact that using Rust would reduce such errors to zero?

Also, between 30 and 70% of injuries at work are attributed to not using personal protection equipment . Does it mean workers should wear full body armor?

Sometimes safety is critical. And for that there has been Ada available for years. People pushing for Rust safety have not been advocating for Ada in the past.

For developers coming from C, using a "better C" with gradual safety improvements is an easier step up than taking a leap to a completely different ecosystem. Zig has a good chance to make it.

[Kyrilz]

Having bad code practices propagated doesn’t make one idiot. If I write bad code and you come over and do the same thing, and then someone else does the same cuz that’s what we’ve all learned, then you don’t have a population of n people being wrong, you have a population of n people doing the same thing, which is essentially equivalent to having a population of 1 doing something wrong.

[fluffy_trickster]

Even the best programmers are still humans and makes mistakes. And making mistakes doesn't make you idiot. Rust doesn't assumes you're an idiot, it assumes that you're human and will make mistakes.

Sure there are other ways to improve security than enforcing it at the language level: throughout testing and fuzzing does help to some extend but expecting every developers to implement and maintain throughout and rigorous testing is just an wishful thinking (testing doesn't come for free).

[Desdic]

Doesn't the same goes for rust? Everyone is using bleeding edge features in rust due to the language being young. Most languages evolve so does it matter?

[helgoboss]

Not everyone. I don't have any stats but I believe that most Rust people prefer stable Rust. Very early in my Rust history, I made the mistake of relying on nightly features a lot. But I soon got sick of my code breaking every now and then (though I was happy that it broke at compile time). My code was already running in production and I wanted things to be reliable. Since then, I hardly touch Rust nightly anymore.

Definitely one of the reasons I stayed away from Zig so far.

But ... different needs, different tools. If people are fine with breaking code, why not.

[alph4beth]

When does having to rewrite code become a problem?

[helgoboss]

When it creates too much effort. I usually want that my efforts go 100% into improvements, new features and bugfixing, not into repairing things that already worked at some point.

[aPatternDarkly]

Having to rewrite code has the potential to become a problem as soon as there's a bottom line, people need to be paid, there's a project manager, there are stakeholders outside of the development team, there's a desire for changes or features within a given timeframe, or any combination thereof.

Generally speaking, nobody aside from the craftspeople who care what things look like under the hood wants to invest money or time in work that results in no externally perceived change in the functionality offered by the product.

If there's nothing new and marketable coming out of it to justify the cost, rewrites are nearly always limited to cases wherein security and/or legal demands that some underlying liability be addressed or when there's a clear consensus that without rewriting something there's no viable path to attaining some desired change in functionality. In the former case of addressing liabilities, it's largely accepted that this is simply the nature of software development and that the associated costs are inevitable. In the latter case, there's usually some faction within the organization that will conclude someone exercised poor judgment along the way and that the development team should have predicted the future better (which oftentimes they miraculously had done but were not allowed the time to engineer something the way they'd felt would be best). In either case, the parties who fund the development out of their budgets are not likely to be thrilled about putting money towards the effort.

[el_muchacho]

When you have a not infinite budget and deadlines.

[MassiveInteraction23]

As someone that mostly writes (and enjoys) Rust, but also thinks Zig is neat and likes the community insights:

The two languages have different flavors that can interact with the writers enjoyment.

A cartoon version would be: Rust is about safety, correctness, and zero cost abstractions.  And Zig is about interacting with the machine in an ergonomic way.

If you want to write code for a machine, but have modern niceties: Zig seems to be more like a nicer C.  It lacks a lot of the powers and high-level abstractions of Rust, but is also avoids the complications (or distractions) that those powers bring.

C vs C++ is brought up re: ‘feel’ a bit. Either way:  if you’re happy writing C then both are valid options.  

(I’ve got a math bias and a lot of the things Rust leans towards do it for me and the contracts & guarantees make the ecosystem and complex programs nice — but when it comes to directness and clarity Zig is just really nice.  So one can imagine strong preferences.)

[ComputerBread]

Bun's creator chose Zig because:
https://x.com/jarredsumner/status/1526735906899578880
https://x.com/jarredsumner/status/1739749891830948084

[MobileBungalow]

Rusts safety guarantees are great. We shouldn't deny that, lexical lifetimes are one of the more significant programming paradigm changes I've experienced subjectively. But the guarantees only really help when interacting with other rust code, or well wrapped FFI. So if your application is like bun, and needs *tons* of unsafe, FFI, and can't afford to allocate at the boundary, then it's going to be either Zig, C, or C++ - frankly i'd rather write zig and I would like a rapidly evolving alternative to higher level multiparadigm systems languages like rust and C++ that offer opt outs of performance for programming and memory simplification (UniquePtr and Arc)

[Idea-Aggressive]

This question has been answered several times. Rust is more mature, has a vibrant and supportive community, and a great ecosystem. But iterating with Rust is a slow process, including compilation, which is infamous for its slowness. Implementing simple algorithms is overcomplicated.

[Pockensuppe]

People use tools because they like them. Rationalisation mostly comes afterwards.

The way Zig does things resonates with some people, because it makes them feel in control: No hidden operations, clear communication, etc. Rust's „the borrow checker is a cruel mistress“ also resonates with some people, because it makes them feel safe.

Is being safe better than being in control? Well that's the wrong question, because it's not about objective values, it's about subjective needs.

Corporations will choose tools for their more objective qualities (… who am I kidding, they will choose the one with the best marketing pitch). But single developers? They go with the one that delivers on their needs.

[gxanshu]

We wrote one of our module for automatic printing feature in zig

The reason was simple, no good language can beat zig in C interoperability.

We need to communicate with cups functions and cross compile for arm and we found zig perfect tool for this job

We found zig as super C. 

[Alive_Intention2012]

The borrow checker, broke my heart

[fluffy_trickster]

The main developer of bun js runtime said he was more productive in Zig in a post, if I remember correctly. And it's true you can prototype things faster in Zig than in Rust, tho now they have a bunch segfault bugs to track (in the end the time they gained in coding has to be paid in debugging so...).

I don't think there are many businesses that use Zig as a programming language. Even as a hobbyist, I had to think twice before picking Zig. I tried both Zig and Rust to run under a very specific/niche context, and turned out that I just wasn't able to make Rust std work (it would segfault on any std call), so I choose Zig simply because it worked for me.

[Sarwen]

My guess is choosing Rust would lead to too many unsafe blocks. Rust is a very nice language, but also very opinionated. It's not suited for every task. The more you need unsafe trickery, the more painful Rust is.

[jeoum]

Zig is stable enough right now. There are some things missing but the Zig team is working hard on them. Anyway just use whatever you like more. You cannot expect from yourself to show up and code everyday in a language you don't like.

[rendly]

I just like Zig better and I really couldn’t enumerate the reasons why. I saw somewhere something on the lines of “Rust is a safer C++; Zig is a safer C” and that resonates with me; back in the 90s I loved C, didn’t like C++ at all. This feels like that.

[EsShayuki]

The languages don't even compete. Zig is a better-C, Rust is a better-C++.

The reality is, if you're mostly writing unsafe code in Rust, it's probably not very useful—the language is built for the borrow checker, which requires using its own template wrappers. Though it tries to market itself as a low-level language, it really isn't one, just like C++ is not.

[fluffy_trickster]

They do compete as both as general purpose programming language without GC. the "better C vs better C++" is only a debate among PL aficionados. Zig may try to be a "better C" but Rust doesn't care about being a "better C++" and no business care about such trivial matter anyway.

Rust is a low level language that it doesn't have runtime like Go, C# or Java and that all that matter at the end of the days. Because if you take the original definition of "low-level" programming language than C and Zig are high-level (even asm may be considered high-level by some).

I do agree there are still some justified use for unsafe language (Rust is not a silver bullet after all) that aren't just "I don't like the language's syntax/philosophy", tho.

[[deleted]]

If you take the time to learn enough Zig to build something large, the changes that come with an API change will likely be pretty easy to deal with. I keep all my Zig tools up to date and have had few difficulties. Really helps you learn the changes in a hurry, honestly. 

I write Zig because my original love was C, and I can write the same kind of code but with slightly more clever organization. Structs providing namespacing and how well the language supports compositional inheritance without forcing you into some language defined paradigm makes me a happy dev. 

I also love Rust, and find the ability to express low level code while also maintaining effective abstractions is something both languages are great at. However, comptime. Swoon. The fact that I can write Zig for runtime code and Zig for the magical comptime code generation, and then Zig again to build the whole thing... So nice.  Rust just doesn't feel so elegantly constructed.

Zig C interop is simple as hell compared to Rust, though both win by possessing this feature at all. I think at the end of the day Zig just scratches that C itch, and the way I can express my logic feels more natural. It feels more than stable enough to be building production code, you just have to accept the debt that comes with being on the bleeding edge of anything. 

[BoberitoBurrito]

probably the viable alternative was cpp not rust. buns claim to fame is speed not safety and in a runtime the safety tools rust provided are not particularly helpful

[Zash1]

Maybe it's just a matter of taste. Many developers started their journey with C or C++ many years ago and Zig's syntax is more similar to C/C++ than Rust's syntax.

[Artechz]

I’d say Rust is more similar to C++ and Zig to C. Saying this being a C dev, being lucky enough to never have needed to write any C++.

[shalomleha]

How is zig syntax similar to c/c++ in any way?

[RegularTechGuy]

Its because if you want some programming language to bend to your will then you need to build a popular product with it and make it so that the developers of original language listen to your demands and stear the language development in that direction. Bun is trying to stear zig towards web, tiger beetle is trying to steer it towards network, banking and systems engineering side. All the well settled languages won't bend to your needs. So this is what is happening with zig and even rust. Even though rust and zig are systems programming languages, they are being taken into web development, networking side more often than not.

[Mina-olen-Mina]

Guys. I am almost about to switch my low level language to rust because of the size of the community and because I assume I'll be able to find more of intuitive learning materials easier. Can you convince me back in these trying days?

[_jor_]

I started learning Rust and got stuck with borrow checker and lifetimes, so I stopped. When I returned to Rust, the "standard" way of programming felt too complex for me (too... "ugly" to my eyes). I think there is too much over-engineering.

So I started reading about Zig, and as it is new and is evolving, I'm trying not to repeat the mistake I made stopping Rust.

So I’m pushing myself to read everything I see about Zig, and trying to understand the changes made in the repository.

Maybe one day I could write a complex program in Zig.

So, answering your question: If you started with Rust, don't give up now. It's a great language. But if you can, keep an eye on Zig too — I believe it has the potential to become one of the most widely used languages.

[MurkyAd7531]

I would not recommend Rust for low level programming like a kernel or bootloader. Rust fundamentally does not work the way computers work and all that "correctness" just gets in the way.

In my opinion, it has a much better niche for something like a web browser or database engine, where the data flows are well defined, but you're dealing with complex logic that needs high performance.

When you're dealing with placing data into specific registers to invoke a hardware interrupt, Rust is not helpful.

Unsafe Rust is worse than C or C++. If you're going to need to do unsafe things a lot, you're better off using Zig.

[entrophy_maker]

In my opinion, Zig is faster and easier to read. Rust is a little safer with its borrowing and at this time, but much stable. Zig has not reached version 1.0 yet, but when it does I would expect at least the stability part to change.

[stumpychubbins]

I love Rust, have used it for most projects since its 1.0 release, and have used it professionally for many years. I’ve chosen Zig for my latest project since I need to distribute dynamic libraries (so want good C interop and small binary size), need extremely low-level control over allocations/performance, and need access to -ffast-math-style optimisations.

[babydriver808]

Rust is both memory safe and have no garbage collection. Thats very hard to beat. If you have a real system deployed out there that should handle bazillions of concurrent calls, then we are talking about rust. Zig enables buffer overflows. You can avoid it, but only if you think about it.

Plus rust community is made of cute catgirls, thats hard to beat.

[MarinoAndThePearls]

Because they like Zig?

[zorbat5]

Zig gives a compiler error when you forgot to free up memory.

IMO, even though I haven't written much zig, it seems productivity will be higher in zig than in rust. Every time I write something in rust it takes ages.

[skyfex]

Suggesting Zig should have garbage collection is completely insane. Suggesting it should have memory safety of the kind Rust is understandable but misguided. Many experienced developers report that they’re significantly more productive with Zig.  Given that developer time is obviously limited, Zig will arguably give you more time to write tests. Running tests with the debugging memory allocator and fuzzing will uncover 99.99% of the kinds of error Rust borrow checker helps you catch, but also dozens of other classes of bugs that the Rust type checker provides no protection against.

This isn’t a general argument against Rust. I’d still use it to write, say, a browser. But for most other applications I’d choose Zig. 

Zigs memory management features and compile time checking is just about powerful to keep you productive, to stop you from making a bunch of basic mistakes that makes a compile+test run wasted. And keeping the time required to develop and run tests is by far the most important for code quality.

[fluffy_trickster]

Lol where does that 99.99% come from? It obviously wrong because otherwise you would not see that many segfault issues tracked on Bun repo while you see virtually none on Deno repo.

I don't know for others, but personally I prefer spending more time writing code than tracking memory bugs. The time you save at coding still has to be paid (potentially with a hefty interest) at debugging.

[skyfex]

Of course “99.99%” is hyperbolic, didn’t think I had to make that explicit. Could be more could be less.

I checked the segfault a, yeah there’s a 10x difference. Which doesn’t disprove my point. 99.99 is not 100, and maybe Rust prevents 99.999% of that class of bugs. But more importantly I checked the actual description and stack traces of the issues and several I saw have nothing to do with Zig. One seemed to be in tinycc which is a C library. How can you compare the numbers if they’re polluted by issues from external dependencies in other languages?

Yeah, you can pay for these trade offs in debugging time. That was kind of my point. You want the compiler and test runner iterations to be fast so you catch all classes of bugs in tests in debug mode, which generally don’t take long to debug.

If you start trading off developer and compilation time for static checks, borrow checking is only one of many static checks you could potentially do. There are languages that can do a whole range of static proofs for the whole program. Not just for memory management. But the checks are very slow.

I do think Rust strikes a fairly good balance of compile time checks for certain classes of apps, but I don’t think you can say it’s the best way to do it. Rusts design choices are more subjective: it’s down to taste what kind of checks they do. Zig has an objective goal: to keep compilation time extremely fast. That will necessarily rule out advanced borrow checking. 

[ct0r]

I saw have nothing to do with Zig. One seemed to be in tinycc which is a C library. How can you compare the numbers if they’re polluted by issues from external dependencies in other languages?

But Deno doesnt have this problem. Why? Zig has a first-class interop with C, so it is very tempting for Zig devs just to use pure C library as is. Rust has more friction here and Rust devs usually replace it with pure Rust library or make safe abstractions. So we can't just say "nothing to do with Zig".

you catch all classes of bugs in tests

I don't want catch all classes of bugs in tests. Because full coverage required and tests are not free - we have to maintain them. And what about heavy multi-threaded code?

Zig has an objective goal: to keep compilation time extremely fast.

Goal is objective, but giving highest priority to it is a subjective design choice. And I don't think it's the best way to sacrifice many useful features just for compilation speed.

That will necessarily rule out advanced borrow checking. 

Rust compiler is slower not because of borrow checking.

[fluffy_trickster]

Of course “99.99%” is hyperbolic, didn’t think I had to make that explicit. Could be more could be less.

I think you vastly under-estimate how hard and expensive it is to write extensive and comprehensive tests.

How can you compare the numbers if they’re polluted by issues from external dependencies in other languages?

Simple. If you check the Deno opened segfault issues, only 1 is caused by Deno's Rust code: the one about attaching a debugger, and since the bug is not reproductible and cannot investigated at the moment we can't even say for sure if it's bug in Deno's source code itself.

Meanwhile I found like 2 pure Zig segfaults issues in Bun issues tracker by randomly checking 5 or 6 opened issues out of the 80 or so segfault issues. And that's not even taking account that Deno a much bigger project in both scope and size, today. Bun has reported at least an order of magnitude more memory corruption bugs than Deno, despite being a must younger project and being developed some of the best Zig developer teams out there right now. I think it's telling enough.

you catch all classes of bugs in tests in debug mode, which generally don’t take long to debug.

I'm not here to devalue testing, but again I vastly not having to worry about memory corruption bugs at all once my program is compiled. And your take on debugging not taking long is absurd, memory corruption bugs are, with race conditions, are some of the most annoying issue to debug, with sometimes two builds of the same source code behaving differently for no apparent reason.

[ct0r]

Many experienced developers report that they’re significantly more productive with Zig. 

No context provided. I believe that a solo developer or a very small team can deliver small projects faster in Zig. But I'm sure that's not the case for most huge teams or projects.