Hacker News Reader

Comment by sarmadgulzar | Hacker News Reader

I know I'm biased, but Rust is the closest thing we have to a perfect programming language. Is the borrow checker a pain in the ass? Yeah. But is it necessary? Absolutely. Imagine writing the same buggy program in C, deploying it, and then it blows up at runtime—you still have to fix it, right? A bug is a bug, and it needs fixing. The difference is Rust forces you to deal with it before you even get a binary, while with C you might get a 3 a.m. wake-up call trying to figure out what went wrong. So it’s not that Rust is harder, it’s just different. It takes a paradigm shift in how we think about writing safe and secure code. Change is uncomfortable in general for humans and that paradigm shift is precisely why most (I hope not) people feel this way about Rust.

View on HN

Rust is far from perfect.

* I think Rust gives the compiler too much freedom to choose whether or not to apply Deref (and in what order). The whole .into() and From trait allows the compiler to perform arbitrary type conversions to make the code work (the standard library is full of similar "convenience" traits and functions). All of these tend to hide the types of a objects, making it hard to map a function call to an implementation (though a good IDE can help with that). * I think implicit return values is a misfeature as it makes flow control implicit, hiding it from programmers reviewing the code. I'm also not fond of the question mark operator, though syntax highlighting helps a lot with that. * Rust modules are generally too small so that you need hundreds of dependencies to do anything useful. Each of which you need to separately vendor and periodically update if you need deterministic builds. * Async Rust is a hot mess right now

I didn't say perfect, I said closest to perfect. Regarding the implicit return types, it's all a matter of taste. I think they're very clean, but Rust is not forcing you to be implicit—you can be explicit if you like. e.g., if a function's return type is String, then whether you write the implicit "Hello".into() or the explicit "Hello".to_string() or String::from("Hello") is entirely up to you, and Rust will not complain.

> Is the borrow checker a pain in the ass? Yeah. But is it necessary?

You've missed the primary point of the post entirely. Borrow checker per se is not the problem; it's the sheer amount of everything. There's multiple ideas of perfection. Those of us to have very much enjoyed ostensibly imperfect Rust of 2018 find this particular, current flavour unappealing. It may as well be capable tool in deft hand, however, as-is the case with everything in life, you cannot help but ask yourself THE question; is it worth my effort? For me personally, if I were looking for better C/C++ in 2025, I would choose Zig before Rust any day of the week (one exception being Postgres stuff, pgrx ecosystem that is really special!)

But then again, anything beats writing C for a living.

Traits, generics, ownership, RAII shows up in many languages, so what other concept outside of lifetimes does Rust introduces?

Affine types, variance, higher-rank trait bounds, phantom data, MaybeUninit, and the whole macro and proc-macro systems are some examples of concepts that I found to be challenging when learning Rust.

Dyn-safety is another but I had encountered that previously in Swift.

> But then again, anything beats writing C for a living.

I love that.

My happiest professional programming has been C

I guess diversity of taste is a wonderful thing?

Yes, I also love writing C.

Guilty pleasures :3

> Those of us to have very much enjoyed ostensibly imperfect Rust of 2018 find this particular, current flavour unappealing.

I believe everything in this post (except `cargo -Zscript`) was in the Rust of 2018.

Reply on news.ycombinator.com