Hacker News Reader

Comment by WhatIsDukkha | Hacker News Reader

This seems like a weird use of Rust.

There is no mention of how much of the codebase is even in safe Rust after all this work so no clear value to the migration?

Frequently when people get their code ported they then begin a process of reducing the unsafe surface area but not here.

The author seems to have little or no value on safe Rust? It doesn't seem evident from reading/skimming his 4 articles on the process.

Interesting mechanical bits to read for sure though so it' still a useful read more broadly.

It's unsurprising that the author would go use Zig next time since they didn't seem to have any value alignment with Rust's core safety guarantees.

View on HN

> It's unsurprising that the author would go use Zig next time since they didn't seem to have any value alignment with Rust's core safety guarantees.

I don't think that's true. The end application talks to smart cards. See also one of the links: https://gaultier.github.io/blog/how_to_rewrite_a_cpp_codebas...

However, the codebase has the possibility to use multiple memory allocators, and Rust is simply actively bad when faced with that.

It just seems like the codebase has a set of idioms that really lean into the areas that Zig is actively good at and where Rust is weak. Memory allocators, lexical (not RAII) defer, C interop, C++ interop, and cross-compilation are Zig's raison d'être, after all.

The one thing I disagree with is the complaint about "repr(C)". Sorry, but I've become convinced that if we want our compiler and languages to work well on modern hardware, we're going to have to allow the compilers to do lots of struct-of-array to array-of-struct (and vice versa) transformations depending upon the actual access patterns. That means that a struct or an array will not be locked to a specific memory layout unless you specifically request as such.

>Doing an incremental rewrite from C/C++ to Rust, we had to use a lot of raw pointers and unsafe{} blocks. And even when segregating these to the entry point of the library, they proved to be a big pain in the neck.

That's how the project ended up in such a bad state by the end. Instead of having rust-rust linkages that the compiler could check, they designed every function boundary to be an uncheckable rust-* linkage. This would be like porting a C library to C++, but only moving one function at a time, such that every single function had to comply with extern C.

Here is an important warning:

The difficulty of setting up boundaries to unsafe languages are the hidden reason for people wanting to rewrite every C library in Rust. Do not choose a design pattern that requires more than one of these boundaries to exist within your own code!

I don't really understand why they chose to rewrite this in rust if they're just going to spend their time writing unsafe C code in rust.

Unsafe Rust is much safer than C

> Unsafe Rust is much safer than C

That is not at all an obvious axiom.

I am willing to concede that "Rust" is safer than "C".

However, in "unsafe Rust" it is super easy to violate a Rust API precondition that the compiler takes advantage of. Even the Rust intelligentsia have pointed out that writing correct "unsafe Rust" is significantly harder than writing correct C.

Do you have source on that? I would like to know more. Not disputing this, just curious.

https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/

HN discussion: https://news.ycombinator.com/item?id=41944121

While we at it, someone argued that Zig is nicer than unsafe Rust: https://zackoverflow.dev/writing/unsafe-rust-vs-zig/

Thank you, appreciated!

To add on, unsafe Rust's main strength is the tools and the culture of encapsulating it well. It's probably the case that "well designed code that uses unsafe" is much safer overall, as you would expect for a memory-safe language. But it doesn't just come about from using unsafe.

Reply on news.ycombinator.com