this post was submitted on 03 Oct 2024
49 points (87.7% liked)

Programming

17313 readers
357 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 1 year ago
MODERATORS
[email protected]
[email protected]
[email protected]
49
Zig vs Rust. Which one is going to be future? (snac.bsd.cafe)
submitted 1 month ago by [email protected] to c/[email protected]
85 comments fedilink hide all child comments
 

Zig vs Rust. Which one is going to be future?

I think about pros and cons and what to choose for the second (modern) language in addition to C.

@[email protected]

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 14 points 1 month ago* (last edited 1 month ago) (1 children)

Is zig memory safe by design? If not, rust will "win". Large companies aren't going to hire for an unknown or unpopular memory unsafe language when they already have C or C++ - there's just no contest.

Last I read, zig didn't even have a standard string library. Unless that changes, it won't even be a viable alternative to C/C++.

Edit: I checked and got this

the Zig language, like C, entrusts memory management to humans, placing full trust in human development. Zig then provides some memory safety checks to ensure memory safety. However, it still lacks the strict compile-time guarantees of Rust’s ownership system and borrow checker. Therefore, when writing Zig code, developers need to pay more attention to potential memory safety issues and ensure that errors and exceptional situations are handled correctly.

Rust Magazine

Anti Commercial-AI license

[–] PushButton 0 points 1 month ago (3 children)
  • Zig uses allocators, which will inform you if you are leaking memory.
  • Zig comes with defer/errdefer to simplify the resource cleanup (and for ergonomics).
  • Zig comes with Optionals to manage nulls.
  • Zig comes with slices (ptr + size) to manage all the bound-checking.
  • Zig automatically check for overflow/underflow arithmetic.
  • Zig will check for pointer alignments when casting between pointer types.

=> Zig is designed to make you do it right easily, and very hard to do it wrong.

In other words, Zig will let you be, but warn you when you are doing something wrong, where Rust is like Karen who is always screaming at you for every word you are typing.

To summarize, you really need to /want/ to fuck up to fail your memory management... If after all that you still can't manage your memory, it might be better for you to look for another carer.

Something is sure thou, Zig is very safe - just as it's safe to cut my veggies with a knife. I might cut a finger and bleed a little bit, but I will not use plastic knife "because it's safer".

Moreover; You are talking like if Rust is safe, all the time, which is not true in reality:

52.5% of the popular crates have unsafe code. Therefore, in an average real-world Rust project, you can expect a significant number of the dependent crates to have unsafe code -- Source

Basically, you're comparing a hypothetical world where Rust is always safe to a superficial glance at Zig's capabilities to claim a "winner" here.

And for the String library... Are you fucking serious? Do you want to compare the Zig's Std library versus the famously tiny Rust Std library? Really?

[–] Giooschi 4 points 1 month ago (1 children)

Zig uses allocators, which will inform you if you are leaking memory.

Does that hold for the release allocator too? It also requires the leak to happen in your testing (not differently from C/C++'s sanitizers)

Zig comes with defer/errdefer to simplify the resource cleanup (and for ergonomics).

Which you can forget to use though.

  • Zig comes with Optionals to manage nulls.
  • Zig comes with slices (ptr + size) to manage all the bound-checking.
  • Zig automatically check for overflow/underflow arithmetic.
  • Zig will check for pointer alignments when casting between pointer types.

All of this is good, but does very little to ensure temporal memory safety.

To summarize, you really need to /want/ to fuck up to fail your memory management...

I don't see an argument for this. It still seems very much possible to fuck up temporal memory safety without realizing and without hitting it in testing.

52.5% of the popular crates have unsafe code

Which is not unexpected to me. Half of Rust's point is to encapsulate unsafe code and provide a safe interface for it so that it can be locally checked. This is the only practical way that verification can happen, while C/C++/Zig basically force you to do whole-program verification (generally not practicable) or relying on testing/fuzzing/sanitizers (which will never guarantee safety).

[–] PushButton 1 points 1 month ago* (last edited 1 month ago) (1 children)

Does that hold for the release allocator too? It also requires the leak to happen in your testing (not differently from C/C++'s sanitizers)

I really don't see your point here. Of course you have to catch the coding problem in your development phase; just like Rust is omitting overflow checking on release for performance reasons... I will just pass on that one, I am probably missing something here. At release, it's a little too late to debug your code... Rust, Zig, C. Java, whatever the language.

All of this is good, but does very little to ensure temporal memory safety.

The allocators can be scoped to manage lifetime and the explicit nature of the memory management in Zig make it hard to miss manage the lifetime of your allocations. It's not like C/CPP where you have to open the code and check within the function to know if some memory is allocated. There is an "init" function, if it takes an allocator, you know there is memory allocated in it (or the struct, right) so you manage that Allocator for that lifetime instead of managing 'a 'b 'c for each individual variable.

So, basically, you are managing Arenas of variables instead of managing the lifetime of every single, individual variable, one at a time.

What's cool with that is you can manage the memory differently for each allocation by using a different type of allocator, which give you more control if desired.

Do you want to talk about the covariant, invariant, contravariant and invariant in Rust? Because that's a hell of a topic to manage the lifetime in Rust. Don't forget, you have to manage that for /every/single/ variables, one a time. Good luck keeping you sanity in a large project.

You are not helping yourself without those "smart pointers".

Here is a good talk about what I try to tell you: Individual Element Thinking

Also, Zig has some compile time check in form of compile time assertion, checks based on the variable scopes and the defers in the code...

Temporal memory safety is more complex than just saying "GC or Rust". You think it is because this is what you know. What I am telling you is, there are other things out there. => Same dude, 5mins, just a couple of examples of other things

And if I might ask, I always find it funny when a Rust programmer shits on a GC, while he's using Arc every/fucking/where :D

Security goes beyond "smart pointers". Just think of the fact Rust doesn't have shared libraries. If there are, I don't know, let's say 10 Rust software on my system and there is a vulnerability Because Rust also has that fyi; I would have to know exactly that I have those 10 Rust software on my system, check the dependency tree to see if there are affected by the vulnerability (fucking good luck with that!) and recompile all the ones affected to patch all of them, instead of just recompiling the shared library.

See, that's an issue Rust people don't talk about, but that's a serious issue nonetheless.

Zig has nothing to envy Rust.

Now, let's talk about the language interop, the simplicity and elegance of the language, the reflection mechanism, the compile time for example...

Rust people think that this golden cage (borrow checker) is all what matter for a language; it's not the case.

[–] Giooschi 1 points 1 month ago

So, basically, you are managing Arenas of variables instead of managing the lifetime of every single, individual variable, one at a time.

How does that handle stuff like vector reallocation? Does it keep both the old and the new vector allocation around until the arena scope ends? That seems very wasteful and I doubt it is how the release allocator handles it.

What's cool with that is you can manage the memory differently for each allocation by using a different type of allocator, which give you more control if desired.

This creates the risk of using the wrong allocator for deallocating.

Do you want to talk about the covariant, invariant, contravariant and invariant in Rust? Because that's a hell of a topic to manage the lifetime in Rust. Don't forget, you have to manage that for /every/single/ variables, one a time. Good luck keeping you sanity in a large project.

Variance is the property of a type, not a variable. You don't have to "manage" variance, you just have to respect it. And lifetime variance as a concept is something that exists in C/C++/Zig too and has to be respected, but the compiler generally does nothing to tell you about it. If someone doesn't understand that then I fear for what they will write in a language that doesn't make it clear to them.

Here is a good talk about what I try to tell you: Individual Element Thinking

I'm not going to spend my time watching a video just to reply to some random guy online, but I will try to give it a go later on if I have time in case it is actually interesting.

Security goes beyond "smart pointers". Just think of the fact Rust doesn't have shared libraries.

Shared libraries are in fact a massive source of unsafety since there's almost no way to guarantee compatibility between the two sides.

And being able to track dependencies with a proper package manager like cargo already does a pretty good job at tracking what you need to update.

Because Rust also has that fyi

Most of which are actually denial-of-service, unmaintained crates, or unsoundness in some crates.

Unsoundness "vulnerabilities" which would just be considered "documentation issues" in languagues that don't take memory safety as seriously, or maybe they would never be found because you have to go out of your way to actually hit them.

[–] talkingpumpkin 0 points 1 month ago* (last edited 1 month ago)

I've not looked into Zig yet (just like you must not have looked very closely into rust, since most of the stuff you mention as a Zig highlight is present in Rust too), so I'm not gonna argue which one may be "better" (if I had to bet, I'd say both are great in their own way - OP's question is IMHO kinda dumb to begin with).

I want, however, to point out a misconception: "unsafe" rust code is not code that is bugged or in any way inferior to "regular" code, it's just code (usually small pieces) whose safety is checked and guaranteed by the developer rather than the compiler. Yeah, they really should have picked a different name for it... possibly one that isn't literally the contrary of "safe".

[–] calcopiritus 0 points 3 weeks ago (1 children)

A crate having the unsafe keyword doesn't make the crate unsafe. The unsafe keyword just tells the compiler: "I know that what I'm trying to do may lead to memory safety issues, but I, as the programmer guarantee you that the codeblock as a whole is safe, so turn off some of your checks".

Using the unsafe keyword in rust is no much different than using a C library in rust.

[–] PushButton 1 points 3 weeks ago (1 children)

It's when you're at the point of saying that unsafe is safe, it's the point where you should just shut it up kid...

[–] calcopiritus 1 points 3 weeks ago (1 children)

I don't know why you are being so rude. I thought it was the rust community that was known for being toxic?

It's not my opinion on what the unsafe keyword means. That's its purpose. Nobody ever wants to write unsafe code on purpose. The unsafe keyword was created to allow safe programs to be created in rust that wouldn't be accepted by the strict rust compilers.

In a Venn diagram, there are 2 circles: safe programs (1) and programs that are deemed safe by the rust compiler (2).

Circle 2 is smaller than circle 1 and entirely contained inside it. However, there is no reason to not let people write programs from circle 1 that aren't in circle 2. The unsafe keyword exists to enable programmers to write those programs in rust. However, it comes with a warning, now the programmer is the one responsible for making the program inside circle 1.

[–] PushButton 1 points 3 weeks ago

Ok I understand now. You are right. Thank you.