3 ms·

Rust screams a nightmare to maintain (coworkers endlessly bikeshedding over the type signatures, insanely long PRs for refactors needed prior to feature work)

empath75 2y ago
I've been writing rust code in production for 2 years and none of that happens, and this is with a team that was relatively new to rust.
mav3ri3k 2y ago
You examples seems to be for a dynamic environment where things are changing. Rust is naturally at slight odds in such a scenario Instead of quick and dirty, it allows to embed the logic in the type system such that the compiler can help you. Getting off the ground is much harder but staying there is easier. .
- throwawaymaths 2y ago
  Maybe the compiler (and the syntax) isn't the right place to put these guarantees. Surely there is some middle ground in design space between rust and ada on one side (fully in the compiler) and c (with sel4-style checking - proof checking on a post compilation artifact) on the other. Note that the c in sel4 and ada have stronger safety and correctness guarantees than rust
  - bobajeff 2y ago
    I'm curious about the c with sel4-style checking that was mentioned. Does sel4 have a style checker and/or proof checker that you can run on your c code? Or do they just have some style guide you have to read and memorize?
    - aw1621107 2y ago
      > Does sel4 have a style checker and/or proof checker that you can run on your c code? The specification and proofs are open-source [0], but I suspect that they are tailored for seL4-related uses and probably aren't well-suited for "general-purpose" C code. I think using their proofs would also necessitate writing a specification for your own code which is probably going to be an ordeal in and of itself. They do have a style guide [1] as well, but that's just a small part of the full verification process (described in [2]). [0]: https://github.com/seL4/l4v https://github.com/seL4/l4v [1]: https://docs.sel4.systems/processes/style-guide.html#verification-requirements https://docs.sel4.systems/processes/style-guide.html#verific... [2]: https://trustworthy.systems/publications/nicta_full_text/7371.pdf https://trustworthy.systems/publications/nicta_full_text/737...
  - redman25 2y ago
    If you’re ok with sacrificing a small amount of performance for usability, just throw `clone()` everywhere. It will satisfy the compiler. Rust can be written as simply as you want it to be written. Or, you can go crazy with generics or metaprogramming.
    - dns_snek 2y ago
      > Rust can be written as simply as you want it to be written. Or, you can go crazy with generics or metaprogramming. In theory you can do that, in practice you can't. Becoming a good $language programmer necessarily involves reading other people's code, for example when diagnosing issues in misbehaving libraries. You have to be familiar with every common language feature that other developers use, otherwise you won't be able to do your job properly.
mplanchard 2y ago
3.5 years into maintaining a large rust codebase and this is not my experience at all. Type signature bikeshedding is extremely rare in PRs. Refactors can be large, but the fact that they are possible to do safely across the entire codebase with confidence in the result is a major improvement over most other languages. I wouldn’t go back to writing most other languages if I could avoid it, especially for anything large or performance-sensitive.

empath75 2y ago

I've been writing rust code in production for 2 years and none of that happens, and this is with a team that was relatively new to rust.

mav3ri3k 2y ago

You examples seems to be for a dynamic environment where things are changing. Rust is naturally at slight odds in such a scenario Instead of quick and dirty, it allows to embed the logic in the type system such that the compiler can help you. Getting off the ground is much harder but staying there is easier. .

throwawaymaths 2y ago
Maybe the compiler (and the syntax) isn't the right place to put these guarantees. Surely there is some middle ground in design space between rust and ada on one side (fully in the compiler) and c (with sel4-style checking - proof checking on a post compilation artifact) on the other. Note that the c in sel4 and ada have stronger safety and correctness guarantees than rust
- bobajeff 2y ago
  I'm curious about the c with sel4-style checking that was mentioned. Does sel4 have a style checker and/or proof checker that you can run on your c code? Or do they just have some style guide you have to read and memorize?
  - aw1621107 2y ago
    > Does sel4 have a style checker and/or proof checker that you can run on your c code? The specification and proofs are open-source [0], but I suspect that they are tailored for seL4-related uses and probably aren't well-suited for "general-purpose" C code. I think using their proofs would also necessitate writing a specification for your own code which is probably going to be an ordeal in and of itself. They do have a style guide [1] as well, but that's just a small part of the full verification process (described in [2]). [0]: https://github.com/seL4/l4v https://github.com/seL4/l4v [1]: https://docs.sel4.systems/processes/style-guide.html#verification-requirements https://docs.sel4.systems/processes/style-guide.html#verific... [2]: https://trustworthy.systems/publications/nicta_full_text/7371.pdf https://trustworthy.systems/publications/nicta_full_text/737...
- redman25 2y ago
  If you’re ok with sacrificing a small amount of performance for usability, just throw `clone()` everywhere. It will satisfy the compiler. Rust can be written as simply as you want it to be written. Or, you can go crazy with generics or metaprogramming.
  - dns_snek 2y ago
    > Rust can be written as simply as you want it to be written. Or, you can go crazy with generics or metaprogramming. In theory you can do that, in practice you can't. Becoming a good $language programmer necessarily involves reading other people's code, for example when diagnosing issues in misbehaving libraries. You have to be familiar with every common language feature that other developers use, otherwise you won't be able to do your job properly.

mplanchard 2y ago

3.5 years into maintaining a large rust codebase and this is not my experience at all. Type signature bikeshedding is extremely rare in PRs. Refactors can be large, but the fact that they are possible to do safely across the entire codebase with confidence in the result is a major improvement over most other languages. I wouldn’t go back to writing most other languages if I could avoid it, especially for anything large or performance-sensitive.