Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig and Rust

matklad.github.io

Post reply on HN
Print view View original

71–80 of 247 posts

Re: Zig and Rust

#71

Post by Ciantic »

For those reading only the beginning, one could think that Matt is endorsing Zig over Rust. It's not that, from the article:

> It’s not true that rewriting a Rust program in Zig would make it simpler. On the contrary, I expect the result to be significantly more complex (and segfaulty). I noticed that a lot of Zig code written in “let’s replace RAII with defer” style has resource-management bugs.

I also have read Matt's "Hard Mode Rust", and I think there needs to be a better way. Why can't we have flexible language that can span both styles of allocating resources? I also wonder what TigerBeetle would look like if it were written in Rust using the "Hard Mode".

Re: Zig and Rust

#72

Post by connicpu »

flohofwoe wrote: post #62
crop_rotation wrote: post #19

I tried zig after reading so many HN articles and I am not impressed. You have to remember to free after each allocation. The language is supposed to be simple, yet there exist try, catch, defer, errdefer. Rust enums make defining errors so simple with arbitrary payload. Using data structures in rust is much nicer. I think unless you have some precise needs about memory allocation, and want to control exactly where w…

> ...and want to control exactly where when and how memory is allocated... Isn't this the whole point and the reason why manual memory management is still a thing - and actually getting more important with the ever widening CPU/memory latency gap? There simply is no silver bullet for memory management, you can either have high performance or automatic memory management, but not both. (vastly simplified of course - bu…

There's the third option, which is what Rust and C++ do by default, where types have destructors that are run when the value goes out of scope, but also have mechanisms to be activated manually at a precise moment if you know what you're doing and have specific needs.

Re: Zig and Rust

#73

Post by monocasa »

throwawaymaths wrote: post #61
steveklabnik wrote: post #58

Earlier quoted context omitted.

1. You can do anything you want in Rust, you can make your own collections do whatever you want at any time. 2. These changes are about two things, 2a. the first of which is a trait that represents the concept of an allocator, in case users' code would like to be generic over ones that exist in the ecosystem. You can of course still paper over this yourself but the whole point of a vocabulary trait is so that you don…

sorry, I should have been clear: I meant with a standard lib provided data structure. Thanks!

Yes, the data structures in std are parameterized over the allocator, with Global as the default allocator if not specified.

https://doc.rust-lang.org/std/vec/struct.Vec.html

Re: Zig and Rust

#74

Post by TylerE »

jackmott42 wrote: post #50
netbioserror wrote: post #20

Still not convinced that memory semantics are critical in the vast majority of domains. Incredibly fast speeds can be achieved with simple GC and RC for short-running programs, and programs with sustained runtimes can rely on generational GC. These methods have the advantage of nearly eliminating the need for memory semantics, leaving only business logic behind. The best example might be Nim, which drastically reduce…

You can get the idea that a GC has minimal impact on performance when you just look at things like how fast the GC runs, or what % of time is spent in GC, but that only represents a portion of performance implications, there are lots of indirect effects: 1. More memory is used, which means more CPU cache evictions happen 2. There will be things the language won't let you do, because it is garbage collected 3. There w…

Malloc isn’t free, either.

Re: Zig and Rust

#75

Post by monocasa »

throwawaymaths wrote: post #45
lucasyvas wrote: post #15

Earlier quoted context omitted.

Not the parent, but Zig being much easier to use unsafely is not a good thing IMO. Rust tries to pave a path for all types of developers to eventually learn how to write performant code safely in a way that integrates cleanly. This is a much more practical need for the programming community at this time. I have to agree with the parent - I was interested in looking at Zig eventually, but after reading this I am not.…

the assumption with Rust is that memory safety (or, generally, resource provenance) is something that needs to exist in the type system. Zig is still young, so i would say it's not 100% certain that this shouldn't exist, for example, in a separate step, for example using static analysis. Rust is already bumping into important cases where the typesystem is incapable of resolving things that "you might want its typesys…

FWIW sel4 could have verified the C, they simply decided to verify the machine code so that they didn't have to trust that the compiler correctly complex the verified software.

The issue with more broad formal method use is that it's quite a bit of work. The code to be verified has to be designed on the onset for verification, which limits design choices in interesting ways, and even then the verification code far outweighs the code being verified, at about 25:1.

Re: Zig and Rust

#76

Post by DeathArrow »

netbioserror wrote: post #20

Still not convinced that memory semantics are critical in the vast majority of domains. Incredibly fast speeds can be achieved with simple GC and RC for short-running programs, and programs with sustained runtimes can rely on generational GC. These methods have the advantage of nearly eliminating the need for memory semantics, leaving only business logic behind. The best example might be Nim, which drastically reduce…

The good thing about Nim is that you can chose between several garbage collection algorithms, use no garbage collector at all and do manual memory management or allocate without freeing if the program is short lived and doesn't use much memory.

Also having a C interface is great since you can use any C library.

Re: Zig and Rust

#77

Post by gavinhoward »

In addition to the semantics, part of which I tried to understand and failed [1], Zig also has a problem with compiler bugs.

In that same post, my very first example ran into a compiler bug. This is not reassuring.

(Though to be fair, I've run into more compiler bugs than most do: one in GCC, one in Clang. Maybe I'm just unlucky.)

That, combined with the fact that the bug was still not fixed last I checked, Zig's security bug policy is to consider them non-security bugs until 1.0, and it is still not 1.0 makes me wonder why anyone would choose it for a major project to run in production. That was TigerBeetle's first and biggest mistake.

[1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...

Re: Zig and Rust

#79

Post by sramsay »

netbioserror wrote: post #20

Still not convinced that memory semantics are critical in the vast majority of domains. Incredibly fast speeds can be achieved with simple GC and RC for short-running programs, and programs with sustained runtimes can rely on generational GC. These methods have the advantage of nearly eliminating the need for memory semantics, leaving only business logic behind. The best example might be Nim, which drastically reduce…

I completely agree with what you're saying here and wonder every day why Nim hasn't taken over the world. People seem not to realize that Nim not only has a "pluggable" gc system (so you can pick the gc that makes sense for your use case), but also allows you to turn the gc off. As in, no gc (which is exactly what you need in certain very narrow situations).

Re: Zig and Rust

#80

Post by haberman »

mustache_kimono wrote: post #63
haberman wrote: post #44

> First, I think Zig’s strength lies strictly in the realm of writing “perfect” systems software. It is a relatively thin slice of the market, but it is important. This resonates with me. This is exactly why I use C today, and why Zig appeals to me.

This definition of "perfect" might be counterintuitive for those that haven't read the piece. The idea is there might some ideal memory allocation scenario that Rust doesn't do "perfectly" that you can theoretically do better in Zig, which I buy. Most particularly, my experience with arenas and defer drop is -- they aren't always perfectly easy in Rust. But this definition of perfection tends to ignore all the manual…

> Most particularly, my experience with arenas and defer drop is -- they aren't always perfectly easy in Rust.

That is my experience also: https://blog.reverberate.org/2021/12/19/arenas-and-rust.html

I was hoping the borrow checker would perfectly check arena lifetimes. And it does, but it requires that your types have lifetime parameters. That makes logical sense, but my experience attempting to actually use a type with a lifetime parameter is that it is so painful as to not be practical in a low-level library.

Post reply on HN