[epage]

I'd guess that in 99% of cases, if the borrow checker is a problem for you in Rust then you are likely not ready yet for C or Zig, particularly when you need to work in a team where mainatainability by others is critical.

There are some cases the borrow checker requires you to go through hoops for but I see that as a win for adding friction and raising visibility of weird patterns.

And yes, there are cases that can't be expressed the same way,

[pclmulqdq]

Sometimes, "weird" patterns are correct. The borrow checker doesn't care about nuance.

[yoyohello13]

It’s also true that people overestimate how often the “weird” patterns are needed. 9 times out of 10 it’s the programmer who is missing something, not the borrow checker.

[pclmulqdq]

That has not been my experience with it, but I understand if it is yours. I have often seen people use convoluted or slow patterns to satisfy the borrow checker when something slightly un-kosher would have been simpler, faster, and easier.

[littlestymaar]

unsafe exist for that very reason.

There's no Rabbi out there to mandate that your code is kosher, using unsafe is OK.

Also, the situation where you really need it are rare in practice (in 9 years of full time Rust, I've yet to encounter one).

[pclmulqdq]

Using "unsafe" for things that really need it structurally is incredibly unwieldy and makes all your code a total mess. A single instance of "unsafe" is clean and fine, but if you want or need to use patterns that do not follow the religious "single ownership known at compile time" dogma, you end up spewing "unsafe" in a lot of places and having terribly unclean code as a result. And no, "Arc" is not a perfect solution to ths because its performance is terrible.

I encourage you to write a doubly linked list in Rust if you want to understand what I mean about "un-kosher" code. This is a basic academic example, but Rust itself is the rabbi that makes your life suck if you stray off the narrow path.

I write a decent amount of system-level software and this kind of pattern is unavoidable if you actually need to interact with hardware or if you need very high performance. I have probably written the unsafe keyword several hundred times despite only having to use Rust professionally for a year.

[littlestymaar]

> Using "unsafe" for things that really need it structurally is incredibly unwieldy and makes all your code a total mess. A single instance of "unsafe" is clean and fine, but if you want or need to use patterns that do not follow the religious "single ownership known at compile time" dogma, you end up spewing "unsafe" in a lot of places and having terribly unclean code as a result.

It's only “unclean” because you see it that way. In reality it's no more unclean than writing C (or Zig, for that matter).

> And no, "Arc" is not a perfect solution to ths because its performance is terrible.

There's no “perfect solution”, but Arc in fine in many cases, just not all of them.

> I encourage you to write a doubly linked list in Rust if you want to understand what I mean about "un-kosher" code

I've followed the “learning rust by writing too many linked lists” tutorial ages ago, and I've then tutored beginners through it, so I'm familiar with the topic, but the thing is you never need to write a doubly linked list IRL since it's readily available in std.

> this kind of pattern is unavoidable if you actually need to interact with hardware

You need unsafe to interact with hardware (or FFI) but that's absolutely not the same thing.

> I have probably written the unsafe keyword several hundred times despite only having to use Rust professionally for a year.

If it's not a hyperbole, that's a very big smell IMHO, you probably should spend a little bit more time digging into how to write idiomatic rust (I've seen coworkers coming from C writing way too much unsafe for no reason because they just kept cramming their C patterns in their Rust code). Sometimes, unsafe is genuinely needed and should be used as a tool, but sometimes it's not and it's being abused due to lack of familiarity with the language. “Several hundreds times” really sounds like the latter.

[matklad]

Well said! Having a mental borrow checker running in background certainly helps a lot when coding in Zig. What also helps is that Zig safety checks generally catch lifetime bugs at runtime nicely. E.g., undefined memory is set to `0xAAAA`, which, if interpreted as a pointer, is guaranteed to be invalid, and fail loudly on dereference.