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

191–200 of 247 posts

Re: Zig and Rust

#191

Post by pornel »

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…

They are not for majority of programs, but they are essential in the niches that Rust and Zig target.

This is why it took so long to have a viable alternative to C and C++. Every other language decided "memory management is hard, GC is fine for 99% of programs, let's go with GC", and language after language kept disqualifying itself from the no-GC niche.

From the Rust intro talk: http://venge.net/graydon/talks/intro-talk-2.pdf

> • Everyone is dodging the niche I'm interested in.

Re: Zig and Rust

#192

Post by netbioserror »

pornel wrote: post #191
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…

They are not for majority of programs, but they are essential in the niches that Rust and Zig target. This is why it took so long to have a viable alternative to C and C++. Every other language decided "memory management is hard, GC is fine for 99% of programs, let's go with GC", and language after language kept disqualifying itself from the no-GC niche. From the Rust intro talk: http://venge.net/graydon/talks/intro-…

A great point. As I’ve commented before though, watching webdevs get excited for it, or “rewrite it in Rust,” or developers contort it to try and do things it shouldn’t is sort of morbid from a distance. I’m sure Darwin will work his magic and Rust will settle in the intended niche. But seeing the insane excitement levels and recruiters using Rust to attract applicants…like I said, morbid, and hard to sustain.

Re: Zig and Rust

#193

Post by nextaccountic »

gpderetta wrote: post #142
Animats wrote: post #114

Earlier quoted context omitted.

"(Zig's) collections are not parametrized by an allocator, like in C++ or (future) Rust. Rather, an allocator is passed in explicitly to every method which actually needs to allocate. This is Call Site Dependency Injection, and it is more flexible.' I'd once considered the idea of having "space" as a type. Space is an array of bytes, and it cannot be read or written. Constructors take in "space" and turn it into an o…

This is exactly how C++ work. union { MyObject space; }; // just a bunch of bytes MyObject * myObject = new(&space) MyObject(); // invoke the constructor myObject->~MyObject(); // invoke the destructor If you want RAII use some wrapper like Optional.

Is this syntax new(&something) a new addition? I don't remember it, but then I used to program in C++03

Re: Zig and Rust

#194

Post by molodec »

legerdemain wrote: post #156

Not a particularly deep comment, but... matklad (the author) created, essentially, the entirety of the modern Rust developer experience. He is the original author and biggest contributor to both rust-analyzer and Intellij Rust. If someone this central to the Rust world has switched to writing Zig full time, and not for boring, pragmatic reasons either, a little seed of doubt about the long-term stability of Rust as a…

Grayson Hoare who created Rust has been working on Swift language in the last few years at Apple. People change jobs, there is nothing wrong with that. Rust is a community driven project, and the community will keep building. IntelliJ Rust plugin has not stopped evolving since matklad left. matklad may found a new interesting project that happened to be using zig. He didn't say he left Rust community

Re: Zig and Rust

#195

Post by arc619 »

ibiza wrote: post #99
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…

That's a a compelling argument: GC/RC w/ stack allocation where possible. I associate GC w/ pointer chasing and the unavoidable L1, L2, L3 cache trashing that goes w/ it. To what extent is this possible? Does Nim have LTOs that rewrite memory handling across compilation units? I'm guessing no, and instead it's local & one-off, rather than something one can bank on.

> That's a a compelling argument: GC/RC w/ stack allocation where possible.

Indeed, it's a great combination that means you're productive and performant without really trying most of the time. The type system is really good as well, and in general there's a strong focus on compile time over run time like Zig, but with better procedural macros than Rust.

> To what extent is this possible? Does Nim have LTOs that rewrite memory handling across compilation units?

The GC is built on general move analysis with destructors you can hook for your own types. The nice thing is it's a deterministic, compile time expansion (you can view with '--expandArc:somefunction'), so it's useful for embedded or high performance stuff.

The intro to ARC is pretty good for an overview: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...

Re: Zig and Rust

#196

Post by Dwedit »

_0w8t wrote: post #166
kaba0 wrote: post #155

Earlier quoted context omitted.

Go doesn’t really have a good GC for what it’s worth. And of course there will always be domains where the tradeoffs of a GC doesn’t worth it, but those are very very rare.

The problem with GC is that when it does give problems, there are no good choices. One either spends time trying to tune available knobs to hide the problem or rewrite application to try to reuse objects etc. turning the initial nice architecture into spaghetti mess. I very much prefer for this reason reference counting. Yes, time can be wasted fighting leaks through cycles, one still have avalanches of releases prob…

The real downside to reference counting is concurrency. If the Reference Counter lives in one Core A's L1/L2 cache, then Core B needs to write to the reference count, the cache line is invalidated, and Core A needs to re-fetch it again. You get two cores fighting over the cache line. Everything still works correctly, but it causes some delays if each core is constantly updating the reference counter.

One workaround is giving the threads their own private reference counter (making sure they're on different cache lines), and updating the shared reference counter only when their private reference count reaches 0. Not only do you stop the fighting, you don't even need atomic operations to update the private reference counts anymore.

Re: Zig and Rust

#197

Post by nextaccountic »

haberman wrote: post #96
connicpu wrote: post #72

Earlier quoted context omitted.

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.

RAII is not a silver bullet. RAII wants to have neat recursive ownership and cleanup of everything, which is undoubtedly a nice model, but sometimes in low-level code you have to choose between nice recursive ownership and performance. For example, Protocol Buffers are trees of objects. Originally they were simple and had recursively-owned, heap-allocated nodes. But it turns out that traversing and deleting a big gra…

In Rust terms, the arena should own the data and each object should just borrow from the arena. In Rust, when you drop a borrow it doesn't deallocate the memory; only owned values deallocate on drop (that is, in the destructor). Besides, borrowing enforces that the arena won't drop while the borrows are still outstanding.

https://manishearth.github.io/blog/2021/03/15/arenas-in-rust...

Re: Zig and Rust

#198

Post by bschwindHN »

kristoff_it wrote: post #57
formerly_proven wrote: post #24

Earlier quoted context omitted.

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. https://kevinlynagh.com/rust-zig/

I'm not sure what was available to the author at the time of writing, but it feels like abstractions have gotten better and writing embedded Rust has gotten easier.

I also wrote keyboard firmware in Rust and thought it was great! I leaned on embedded-hal and the chip HAL crates (one layer of abstraction higher than the author in your link) and was able to get the majority of the firmware done in a day or two. For example, here is my key matrix scanning function:

https://github.com/bschwind/key-ripper/blob/d33db6144bbb6f80...

I also gave a small talk on the subject (aimed more at beginners) at a Rust meetup in Tokyo:

https://www.youtube.com/watch?v=x7LQevYn7d0

And finally, a (somewhat) dated article I wrote about using Rust for embedded work:

https://blog.tonari.no/rust-simple-hardware-project

Overall, it feels totally usable to me, and I love how Rust's ownership and lifetime concepts prevent me from doing stupid things like reusing a pin for two peripherals or configuring a peripheral with pins it can't work with.

Re: Zig and Rust

#199

Post by brundolf »

legerdemain wrote: post #156

Not a particularly deep comment, but... matklad (the author) created, essentially, the entirety of the modern Rust developer experience. He is the original author and biggest contributor to both rust-analyzer and Intellij Rust. If someone this central to the Rust world has switched to writing Zig full time, and not for boring, pragmatic reasons either, a little seed of doubt about the long-term stability of Rust as a…

The post is about how the languages serve different purposes, and he just happens to be working on a project now that he believes benefits more from Zig. Nowhere does he make broad-strokes statements about Rust's (or Zig's) fate

Re: Zig and Rust

#200

Post by BenFrantzDale »

nextaccountic wrote: post #193
gpderetta wrote: post #142

Earlier quoted context omitted.

This is exactly how C++ work. union { MyObject space; }; // just a bunch of bytes MyObject * myObject = new(&space) MyObject(); // invoke the constructor myObject->~MyObject(); // invoke the destructor If you want RAII use some wrapper like Optional.

Is this syntax new(&something) a new addition? I don't remember it, but then I used to program in C++03

I assume it’s been around forever. https://en.cppreference.com/w/cpp/language/new (Placement-new is the thing you are talking about.) C++20 has `std::construct_at` which does the same thing but is usable at compile time (in a `constexpr` context) https://en.cppreference.com/w/cpp/memory/construct_at
Post reply on HN