4 ms·

> 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 clas

by Thaxll 4y ago

> 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.

brightball 4y ago
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.
wyager 4y ago
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.
- cozzyd 4y ago
  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...).
- nylonstrung 4y ago
  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
Hirrolot 4y ago
Can agree. Rust-specific things (ownership, AsRef, Deref, all this stuff) drastically pollute the final code, to compare with GC languages.
- Tozen 4y ago
  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.
davidkunz 4y ago
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.
- BiteCode_dev 4y ago
  And the community and philosophy/culture the languages come with seems to promote that as well.
- moffkalast 4y ago
  > 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.
  - davidkunz 4y ago
    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".
    - moffkalast 4y ago
      Yeah I think that's just called enforcing best practices, not optimal solutions.
      - davidkunz 4y ago

by Thaxll 4y ago

brightball 4y ago

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.

wyager 4y ago

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.

cozzyd 4y ago
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...).
nylonstrung 4y ago
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

Hirrolot 4y ago

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

Tozen 4y ago
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.

davidkunz 4y ago

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.

BiteCode_dev 4y ago
And the community and philosophy/culture the languages come with seems to promote that as well.
moffkalast 4y ago
> 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.
- davidkunz 4y ago
  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".
  - moffkalast 4y ago
    Yeah I think that's just called enforcing best practices, not optimal solutions.
    - davidkunz 4y ago