Hacker News Reader

Comment by Thaxll | Hacker News Reader

> bodes well for quality code in general

Built in Rust does not assess of good code quality at all, it just tells you that you will most likely not have a class of bugs or issues, but the code itself can be very ugly.

As a matter of fact given that Rust is "young" most people don't have a lot of knowledge and will most likely copy paterns from other languages, especially when fighting with the borrow checker.

Just open some random Rust code, open the lib.rs and see how things are organized in there, you will be very surprised.

View on HN

It depends.

- Rust is a complicated language, so novice developers probably use something else.

- Its ownership/borrowing system makes sure that architecture is not an afterthought (unless you pollute your code with countless smart pointers).

- You get memory safety in safe Rust code and don't need a garbage collector.

- Non-optimal solutions usually are visible/more cumbersome to write.

In the end it's up to the individual developer, but Rust really helps to produce high-quality code.

And the community and philosophy/culture the languages come with seems to promote that as well.

> Non-optimal solutions usually are visible/more cumbersome to write

How's that? The difference between a suboptimal and an optimal solution can be perfectly valid normal code for lots of procedures. It's not something that's knowable without semantic meaning of what the code's trying to do.

A few examples:

- Rust forces you to deal with errors and "null" values (Option). If you just unwrap them, it's visible.

- Rust requires systems with clear ownership. You can opt out with various smart pointers, it's visible.

- Rust requires you to use Box for heap allocations, it's visible.

Note: I'm not talking about optimal solutions in the sense of "best algorithm", more in the sense of "well thought out and without lazy shortcuts".

Yeah I think that's just called enforcing best practices, not optimal solutions.

One cannot enforce optimal solutions but one can prevent sub-optimal ones through proper checks.

You keep using that word, I don't think it means what you think it means.

Language choice is absolutely a powerful indicator of expected code quality. I don't want to start a language flame war, but I have some heuristics around P(I am satisfied with software|software is written in language X) that are very predictive.

Besides the first-order effects of choice of language on program behavior (e.g. presence of type errors, memory errors, etc.) it also has a second-order filtering effect on the type of people writing programs and their mindset. There are certain languages without a strong first-order effect that nonetheless have a very strong second-order effect.

It's a bit of a curse though, isn't it? If a language becomes popular enough rather than something used only by enthusiasts, then all sorts of crap will appear?

Now there are other issues other than popularity (like you can expect anything written in JavaScript/Python/Java to have a higher probability of a bloated mess, not only because they're popular...).

I think this especially true when someone is explicitly remaking something in Rust to make it more performant

"X but in Rust" IME almost always implies something with at best feature parity, but also debloated code

That's fair. Code quality may have been a stretch.

I'm mostly basing that on what I've read about Rust both here and in various other communities about the guarantees provided by the compiler/runtime itself. I haven't even dabbled in it yet myself, but I plan to at some point.

Can agree. Rust-specific things (ownership, AsRef, Deref, all this stuff) drastically pollute the final code, to compare with GC languages.

To push this argument further along, in numerous use cases the GC using languages have comparable memory safety and performance (thus equal mention by government agencies), but were easier to use or faster for production.

Reply on news.ycombinator.com