Hacker News Reader

I resisted Rust for a long time too. I’ve been using C++ since 2002 and always liked it especially with the modern additions. I liked the idea of Rust early on and even tried it in little amounts and it seemed nice enough, but then over time it just felt over complicated for not enough payout.

Until I learned it for real and forced myself to overcome the hurdles. Now I love it and find it hard to go back to C++. Why would I want to use any language that doesn’t prioritise safety!? Yes Rust can be complex, because things that are safe sometimes can’t be proven to be safe, and then you need a mindset shift to structure the code in ways where it can be proven safe (or if you absolutely need, unsafe lets you isolate the bits that you have to prove yourself. Many people think what’s the point of rust if it has unsafe, but they fail to understand that 100% of your code in other languages is in a rust unsafe block, while in rust at least only the smallest surface needed has to be).

Anyway, yeah, I’m a convert. As for your last paragraph, it’s true, memory safety (and concurrency safety etc) does not mean bug free. But it does eliminate one kind of common high impact error.

How do you feel about pinning in Rust, and how comfortable are you with the aliasing rules of Rust when working with unsafe Rust?

I think more recent languages also provide abstractions that reduce the frequency of off-by-one errors. Type systems also seem to have improved.

Unfortunately, even having tools that eliminate simple errors (like spell checkers and grammar checkers in ordinary writing) does not remove reasoning errors or clarity/conciseness issues.

(Efficient resource use is another dimension besides correctness and maintainability. Using an O(NlogN) method versus O(N×N) may be a mistake when N is small, but tools may lack the domain or profiling knowledge to detect such a mistake. Programming languages also seem to generally lack a way to express the importance of tail resource use, so even with profile information a tool might optimize for mean resource use.)

I think more recent languages have also attempted to increase clarity and conciseness by abstraction and consistent syntax. A newer language may also have more idiom consistency (some of the natural idiom divergence may be less more recently with easier communication -- the Internet functioning like cheap books did for spelling?).

I am not a programmer, but I do like thinking about such things.

> But what kept me away from Rust for a long time is this talking point of rejecting incorrect code which is so obviously wrong it made proponents of Rust sound very cultish to me.

In discussions regarding testing and static vs dynamic languages, I like to emphasize the point that with static languages you get some "tests" for free: the compiler enforcing the contract will "test" that you are not passing in string for integer. With e.g. Python if you want to be defensive and on the correctness side, you need to implement poor-man's type restrictions and tests for the unit so it behaves sensibly with call-site being incorrect.

Does it sound cultish to you to insist on static type checks when e.g. writing Python? There's quite tangible value in that.

> Rust cannot prevent incorrect code, nor is this possible (halting problem).

Yes, nothing will prevent analyst/PO from misunderstanding business requirements, nothing will prevent dev from misunderstanding the technical requirements. Or not thinking things through. Errors on this front will always turnaround.

Correctness in this context refers to programmer's and compiler's understanding of code being aligned. Correct code does what it is supposed to do. Rust takes type safety and elevates it to a next level, ensuring reads, writes and object lifetimes are correct.

Of course, but many languages do many of these things, and have for decades. C is an outlier for not having them, and many big apps use C++ over C for this reason.

Rust's contribution is static resource-use-correctness. Of course, it also implements the other features very well. But if you do not talk about these things in precise terms, it will be harder to convince people to embrace Rust adoption.

Thankfully, Rust is not doing bad for itself in terms of adoption, so what do I know! :)

But it is what kept me from using it for a long time.

> cultish

https://lkml.org/lkml/2025/2/6/1292

> Basically [Rust] can enforce that every resource that is used, is properly opened, is properly accessed, has (one writer) OR (multiple readers and no writer) at a time, and is properly closed. It can do this for memory, files, sockets, as well as arbitrary constructs of your choice.

Unfortunately, this is not true.

https://fasterthanli.me/articles/a-rust-match-made-in-hell

https://old.reddit.com/r/rust/comments/1v54et2/what_are_the_...

Mojo arguably does this better, by having both implicit and explicit destructors, and forcing developers to call explicit destructors, well, explicitly. A lock's destructor must be called manually if it is marked explicit, and thus developers reading Mojo code will presumably not be in doubt about where and when the lock is released.

https://mojolang.org/docs/manual/lifecycle/death/#explicitly...

This is different from Rust. In the following Rust edition 2024 code, the only difference between the two examples is a pair of "{}" around the match subject, but if you run them, one of them deadlocks, due to how temporary lifetime extension is handled in Rust.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Temporary lifetime extension is a mess in Rust, C++ and Zig. It is not a mess in C, more or less, since compound literals are arguably the only feature of C that have something like temporary lifetime extension, so any problems with temporary lifetime extension in C are limited to compound literals.