This is easily lost in the noise, but Matklad wrote a good comparison between Rust and Zig which is worth linking to, highlighting Zig's strengths: https://www.reddit.com/r/rust/comments/123jpry/comment/jdv9x...
Zig and Rust
51–60 of 247 posts
Re: Zig and Rust
#52This title is almost perfectly designed to do well on HN, but it's definitely worth reading in it's entirety. Some highlights for me: - The author sees Rust and Zig in different niches. When Rust was created it didn't need to specialise because there were no languages like Rust. It was free to be a general purpose language targeting multiple domains. But that's not the case for Zig. He sees Zig shining at writing sys…
Zig feels like a good match for replacing C on microcontrollers because it permits “hold my beer” shenanigans and memory management is less of an issue. Zig metaprogramming also seems like a better match for these environments - think about how much nicer you could do stuff like qmk -, the Rust embedded stuff seems quite painful in comparison. Haven’t tried this yet, it’s on my perennial todo list and when I touch th…
I have the exactly opposite experience. Rust move semantics, borrowing, Send&Sync types and checks and type based compile time state-machines is exactly what I was missing specifically on embedded systems in C/C++ and what I'm sorely missing in Zig.
In Rust you start by splitting peripheries to blocks, then to registers, then to register parts and distributes these (these are zero cost operations!) into irq handlers and tasks and the type systems will check that everything that need exclusive access has it .. that you do not use read-modify-write operation on a same register from two interrupts where one can preempt the other without using some guard as mutex.. while it perfectly allow you to do this with write-only registers without guard etc... it is just so nice to work with.
People who find it complicated and/or not worth it are usually doing either some rudimentary super duper easy stuff on architectures or OSes which does not have or utilize nested interrupts or they do it on some IOT like noncritical stuff where they don't give a s** (vs industrial machinery, drones, other vehicles..).
Re: Zig and Rust
#53Earlier quoted context omitted.
Thanks for the example. I wasn't aware this is something that was planned for Rust, seems like a pretty large breaking change. Interesting!
Nothing is breaking! The change isn't a move to a zig-like style, but instead, that in today's Rust, you have struct Foo { // ... } and not struct Foo { // ... } This isn't breaking because there is a default type provided for A. The handwave is over "Today's Rust", as this machinery has already landed, in a sense, it's just not really possible to use with the standard library because the allocator API isn't fully st…
what if you want there to be individual allocators (of the same type) that you want to point differently based on . For example in a M:N greenthreaded system perhaps you want each greenthread to have its own arena allocator. But you can't use something like threadlocal, because at any time a greenthread might move to any given OS thread? Is that possible in rust?
Re: Zig and Rust
#54Still 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…
[deleted]
Re: Zig and Rust
#55May someone chime in between that and make a quick 3-way comparison with Golang? I already know Rust and shipped nontrivial stuff, but I need something simpler that average developers can pickup quickly to produce performant+parallel code and be able to crosscompile+ship a single binary. (The last point already ruled out Crystal which has a poor crosscompilation story as well as insanely long compile times for nontri…
It takes a while to understand allocations in Go. There are obvious ones like `make()` and `new()` and `append()` (though this one doesn't always allocate depending on the capacity of the thing you pass to append, I think). There are less obvious ones (if you don't have experience thinking about it) like string appending and "casting" between `string` and `[]byte`. I think it's also tricky to figure out when escape analysis goes wrong and you're accidentally heap allocating things you didn't need to.
You develop an awareness of these aspects if you do performance-sensitive code in Go. But in Zig all allocations are explicit so you can't really accidentally have allocations.
On the other hand, you have to manually manage memory in Zig. Unlike Rust, Zig has no builtin atomic reference counting. So memory management in Rust and Go are "easier" if you don't want to be aware of memory allocations. Memory management in Zig is "easier" if you need to be aware of memory allocations.
And neither Zig nor Go are as strict as Rust about ownership so it's "easier" to express internally-mutable datastructures in Zig or Go (see "Entirely Way Too Many Linked Lists" [0]). Whereas it's easier to be sure you haven't screwed up ownership in Rust compared to Zig. In Go you don't have to worry since the GC will not let ownership be a problem.
Re: Zig and Rust
#56Still 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…
Frankly, my reason for using Rust is not memory semantics (I'd be happy for most applications with a Gc), it's the type system.
I could be writing in Haskell for an even more powerful type system, of course, (especially now that Haskell has gained linear types) but the language never took hold outside of academia.
Re: Zig and Rust
#57This title is almost perfectly designed to do well on HN, but it's definitely worth reading in it's entirety. Some highlights for me: - The author sees Rust and Zig in different niches. When Rust was created it didn't need to specialise because there were no languages like Rust. It was free to be a general purpose language targeting multiple domains. But that's not the case for Zig. He sees Zig shining at writing sys…
Zig feels like a good match for replacing C on microcontrollers because it permits “hold my beer” shenanigans and memory management is less of an issue. Zig metaprogramming also seems like a better match for these environments - think about how much nicer you could do stuff like qmk -, the Rust embedded stuff seems quite painful in comparison. Haven’t tried this yet, it’s on my perennial todo list and when I touch th…
> Zig feels like a good match for replacing C on microcontrollers because it permits “hold my beer” shenanigans
People who have used Zig to do embedded work have reported the opposite: they like Zig because it helps keep simple things simple and not more unsafe than they have to be.
Re: Zig and Rust
#58Earlier quoted context omitted.
Nothing is breaking! The change isn't a move to a zig-like style, but instead, that in today's Rust, you have struct Foo { // ... } and not struct Foo { // ... } This isn't breaking because there is a default type provided for A. The handwave is over "Today's Rust", as this machinery has already landed, in a sense, it's just not really possible to use with the standard library because the allocator API isn't fully st…
what if you want there to be individual allocators (of the same type) that you want to point differently based on . For example in a M:N greenthreaded system perhaps you want each greenthread to have its own arena allocator. But you can't use something like threadlocal, because at any time a greenthread might move to any given OS thread? Is that possible in rust?
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't have to do all the work yourself.
2b. the second of which is how the collections in the standard library are customized by allocators.
So, in your own code, absolutely you could do that if you wanted to. With this proposal, and trying to do that with a standard library provided data structure? I'm not an expert on the API that it gives, so I can't really speak to its viability here. I would imagine it's not super simple, given what I do know.
Re: Zig and Rust
#59This title is almost perfectly designed to do well on HN, but it's definitely worth reading in it's entirety. Some highlights for me: - The author sees Rust and Zig in different niches. When Rust was created it didn't need to specialise because there were no languages like Rust. It was free to be a general purpose language targeting multiple domains. But that's not the case for Zig. He sees Zig shining at writing sys…
My general understanding is that Zig was made to make video games and Rust was made to make system software, and everything falls out from there.
Re: Zig and Rust
#60The rust-analyzer guy now writes Zig full time?
Yeah that made me wow too!
He's gonna have a wild career.