[mrcsd]

> Writing a substantial amount of unsafe Rust really sucks the beauty out of the language.

I really disagree with this take, given the examples of unsafe code the article chose to exhibit. Trying to write C in Rust totally goes against the grain of Rust's ergonomics, which are oriented towards discouraging unsafe code patterns. It should be a pain to attempt something dangerous, and it should feel really easy to write safe code, because this setup naturally encourages the vast majority of code to be written safely.

[gr4vityWall]

It sounds to me like you agree with the author. They used similar wording to you by the end of their post:

> It was a major pain dealing with all the nuances of unsafe Rust.

[ajross]

This sounds like just prescriptive orthodoxy. In fact lots of applications, including big chunks of Rust's own standard library, need unsafe to correctly express their algorithms (doubly linked lists and balanced trees are famous examples of things that can't be borrow checked, the use case in question appears to be a collected heap which would likewise need to live in the same space).

Deciding that these areas "should be a pain" seems tantamount to saying Rust shouldn't be used for them. Which is sort of the article's point.

[pjmlp]

In Burroughs, still sold as ClearPath MCP, to use applications compiled with unsafe code blocks (NEWP is one of the first systems languages with unsafe concept), the admin has to enable their execution in first place.

Until then the executables are tainted and will trigger an error instead of being executed.

Only the standard library, and OS system tools, as Trusted Computing Base, are excepted from this.

This is the whole point of systems security, everything is unsafe down to silicone, the whole point is reducing the amount of Trusted Computing Base that has to be manually validated and certified.

[do_not_redeem]

Rust's approach is more like a "keep off the grass sign" than a barbed wire fence. If Rust really wasn't meant to be used for these things, it wouldn't have the unsafe keyword at all. But instead of forbidding those things entirely, it just makes them uncomfortable. This nudges the programmer to question if they really need to be on the grass to accomplish their goal, and helps subconsciously steer them onto the safer path.

This is the "strategic use of friction" described here, ironically enough, by the creator of Zig: https://github.com/ziglang/zig/issues/3320#issuecomment-8844...

[ajross]

> instead of forbidding those things entirely, it just makes them uncomfortable

The details in the linked articles rise well above merely "uncomfortable" though. If your response was appropriate, we wouldn't be here discussing them. In particular the interaction between the borrow and aliasing analysis is something I hadn't thought of before, and seems terrifying.

This gets back to my earlier point. The Rust community seems to have abandoned introspection for orthodoxy. You say something interesting about it, and the response comes back as a canon incantation about why Rust is always right. But there are interesting criticisms to be made, people just don't want to hear them it seems.

(In particular the bit about "you can't write dlist in safe rust" routinely seems to surprise people, even reasonably expert Rust developers, I talk to in real life. The flock's dedication to the borrow checker apparently means that no one is allowed to discuss or think about the places where it can't work!)

[pod_krad]

>In particular the bit about "you can't write dlist in safe rust" routinely seems to surprise people, even reasonably expert Rust developers, I talk to in real life.

Actually you can write dlist in safe Rust. But with some overhead in comparison with C, C++.

[kjs3]

Agreed. This sort of handwavy genuflect to some idealized One True Rust Way instead of addressing (seemingly) valid complaints in a direct manor is perhaps the biggest thing pushing me away from interest in rust.