4 ms·

I feel that Rust is something of a religion at this point. Curious how many downvotes I might accrue for expressing that perspective. Might be wrong, but my sen

I feel that Rust is something of a religion at this point. Curious how many downvotes I might accrue for expressing that perspective. Might be wrong, but my sense has been that challenges with Rust are written off in an off-hand way and its features exaggerated. Glad to see promising new languages pushing progress forward, though. I'm head high in C/C++/asm for decades so many of the complaints about those languages fall flat with me since I'm over the hurdles via sheer years of experience.

xiphias 9y ago
It's the first time since I'm alive a language that is higher level than C/C++ can compete with C/C++ in the benchmarks. If you have experienc with large C++ code bases you probably know how impossible it is to write safe code. Also after you use only unique/linear types, single inharitance (which is advised when working with a big code base), you are writing something that's easier to express in Rust than in C/C++. Inlined asm will stay of course, Rust doesn't try compete with it.
- blub 9y ago
  Safety is many shades of grey instead of being black and white and it is intertwined with the concept of risk. The fact that large C and C++ code bases exist and the products they drive are successful proves that it is possible to write code in those languages that offers a good enough risk/reward balance. This is what many Rust fans are missing: you want to sell 100% memory safety, but you're assuming that everyone wants 100% instead of 80 or 90% and that they're willing to pay the price of switching.
  - steveklabnik 9y ago
    If you want to work in a memory-unsafe superset, you can; that's what unsafe is.
    - blub 9y ago
      It looks like you didn't understand what I meant. Each company/project/person needs to make a decision: * I can work in C and C++, which I can get to X% safe using the techniques and tools A, B, C at the cost of M. OR * I can invest in learning Rust and integrating it with my environment to get to 100% at the cost of N. Is the difference from X% to 100% big enough to pay N instead of M? How big of an X do I need? Is it even possible for me to use A, B and C? This is how an informed decision would look like, but Rust proponents just keep repeating that X < 100.
      - rcxdude 9y ago
        Not saying there's a cost-benefit analysis to be done, but there's a pretty nonlinear jump from under 100% to 100%, however. In my experience existing tooling for static analysis on C and C++ tends to be it can point out a lot of bugs, but it can't prove that there's are not bugs (of a particular class). This helps me catch things I miss, but it doesn't free me up from worrying about them (X% safe doesn't been I don't have to worry about X% of the code, which would be great, it means all of the code has a (1 - X%) chance of containing a safety bug, which is far less useful). This cost-benefit analysis also is substantially different between switching an existing codebase and starting a new one. The fact that Mozilla considers it worthwhile to switch an extremely large C++ codebase to Rust is worth noting.
      - steveklabnik 9y ago
        Yeah, we mean slightly different things. I agree with what you're saying, but what I'm saying is about the cost of N; if you find yourself fighting with Rust's rules, you can drop back to unsafe, and use the rules you already know. Well, similar ones anyway. This reduces the cost of N.
        blub 9y ago
        N however can only be decreased by improving Rusts UX. If one is able to write unsafe code in Rust, they already paid the full N.
mikebenfield 9y ago
> challenges with Rust are written off in an off-hand way and its features exaggerated I think people are pretty straightforward about Rust's challenges. The borrow checker can be a hurdle and probably needs more work (although it is getting a big boost soon with non-lexical lifetimes). Compile times are not great. The macro system is powerful but can be confusing. People from some mainstream languages may have trouble wrapping their heads around the type system. Regarding its features, these attributes: * it can do low level, fast code; * it's not garbage collected, but is memory safe; * it has zero cost abstractions (and, conversely, it doesn't have ridiculous, unnecessary, slow abstractions); * it doesn't ignore the last thirty years of innovation in programming languages (by which I mean it has a modern type system, closures, variant types, and a few other things); * it doesn't have 30-40 years of cruft; * it has a standard and very high quality build/packaging system; * its developers are thoughtful and have good taste; * it has a reasonably big community and has a good chance of catching on even more widely; are huge. You say you think its features are exaggerated, but to my mind, what's to exaggerate? That list looks pretty great to me.
- posterboy 9y ago
  half of these "features" are your own subjective opinion
  - erichdongubler 9y ago
    And those are...? It's hard to refute or agree with you when I don't know what you're talking about. :)
  - mikebenfield 9y ago
    They are? I'll grant you the one about the taste of the developers. Which other one is opinion?
    - posterboy 9y ago
      after zero cost abstractions you got carried away.
jdub 9y ago
> my sense has been that challenges with Rust are written off in an off-hand way and its features exaggerated Not by the Rust development team, which is what matters. They are keenly aware of the challenges, and have done a huge amount of work (particularly over the last six to twelve months) working on ergonomics and developer experience. It's a primary focus for the Rust community, now and into the future. Many (perhaps most?) of the specifications lined up for the current "impl period" (a time for building rather than designing) are related to developer ergonomics in some form.
pornel 9y ago
As someone who's been using Rust in production for over a year, and C on and off for 17 years, I can assure you Rust really delivers what it promises. The challenges are not exaggerated, but they do have solutions, so they're not deal-breakers in practice. The learning curve is steep. It takes effort, but once you get it (and unlearn some C-isms), Rust is a quite productive language. Some patters and data structures are not understood by borrow checker, so you have to fall back to coding as-safely-as-any-C program. However, thanks to the practice of wrapping risky bits in safe abstractions, they remain only a small fraction of any program. It might feel that writing any "unsafe" code defeats the promise of Rust, but it doesn't. The concept of safe abstraction is quite powerful, and makes sense even for wrapping 100% C libraries, where you can encode informal constraints form the manual as code, and automatically prevent library API from being misused.

xiphias 9y ago

It's the first time since I'm alive a language that is higher level than C/C++ can compete with C/C++ in the benchmarks. If you have experienc with large C++ code bases you probably know how impossible it is to write safe code. Also after you use only unique/linear types, single inharitance (which is advised when working with a big code base), you are writing something that's easier to express in Rust than in C/C++. Inlined asm will stay of course, Rust doesn't try compete with it.

blub 9y ago
Safety is many shades of grey instead of being black and white and it is intertwined with the concept of risk. The fact that large C and C++ code bases exist and the products they drive are successful proves that it is possible to write code in those languages that offers a good enough risk/reward balance. This is what many Rust fans are missing: you want to sell 100% memory safety, but you're assuming that everyone wants 100% instead of 80 or 90% and that they're willing to pay the price of switching.
- steveklabnik 9y ago
  If you want to work in a memory-unsafe superset, you can; that's what unsafe is.
  - blub 9y ago
    It looks like you didn't understand what I meant. Each company/project/person needs to make a decision: * I can work in C and C++, which I can get to X% safe using the techniques and tools A, B, C at the cost of M. OR * I can invest in learning Rust and integrating it with my environment to get to 100% at the cost of N. Is the difference from X% to 100% big enough to pay N instead of M? How big of an X do I need? Is it even possible for me to use A, B and C? This is how an informed decision would look like, but Rust proponents just keep repeating that X < 100.
    - rcxdude 9y ago
      Not saying there's a cost-benefit analysis to be done, but there's a pretty nonlinear jump from under 100% to 100%, however. In my experience existing tooling for static analysis on C and C++ tends to be it can point out a lot of bugs, but it can't prove that there's are not bugs (of a particular class). This helps me catch things I miss, but it doesn't free me up from worrying about them (X% safe doesn't been I don't have to worry about X% of the code, which would be great, it means all of the code has a (1 - X%) chance of containing a safety bug, which is far less useful). This cost-benefit analysis also is substantially different between switching an existing codebase and starting a new one. The fact that Mozilla considers it worthwhile to switch an extremely large C++ codebase to Rust is worth noting.
    - steveklabnik 9y ago
      Yeah, we mean slightly different things. I agree with what you're saying, but what I'm saying is about the cost of N; if you find yourself fighting with Rust's rules, you can drop back to unsafe, and use the rules you already know. Well, similar ones anyway. This reduces the cost of N.
      - blub 9y ago
        N however can only be decreased by improving Rusts UX. If one is able to write unsafe code in Rust, they already paid the full N.

mikebenfield 9y ago

> challenges with Rust are written off in an off-hand way and its features exaggerated I think people are pretty straightforward about Rust's challenges. The borrow checker can be a hurdle and probably needs more work (although it is getting a big boost soon with non-lexical lifetimes). Compile times are not great. The macro system is powerful but can be confusing. People from some mainstream languages may have trouble wrapping their heads around the type system. Regarding its features, these attributes: * it can do low level, fast code; * it's not garbage collected, but is memory safe; * it has zero cost abstractions (and, conversely, it doesn't have ridiculous, unnecessary, slow abstractions); * it doesn't ignore the last thirty years of innovation in programming languages (by which I mean it has a modern type system, closures, variant types, and a few other things); * it doesn't have 30-40 years of cruft; * it has a standard and very high quality build/packaging system; * its developers are thoughtful and have good taste; * it has a reasonably big community and has a good chance of catching on even more widely; are huge. You say you think its features are exaggerated, but to my mind, what's to exaggerate? That list looks pretty great to me.

posterboy 9y ago
half of these "features" are your own subjective opinion
- erichdongubler 9y ago
  And those are...? It's hard to refute or agree with you when I don't know what you're talking about. :)
- mikebenfield 9y ago
  They are? I'll grant you the one about the taste of the developers. Which other one is opinion?
  - posterboy 9y ago
    after zero cost abstractions you got carried away.

jdub 9y ago

> my sense has been that challenges with Rust are written off in an off-hand way and its features exaggerated Not by the Rust development team, which is what matters. They are keenly aware of the challenges, and have done a huge amount of work (particularly over the last six to twelve months) working on ergonomics and developer experience. It's a primary focus for the Rust community, now and into the future. Many (perhaps most?) of the specifications lined up for the current "impl period" (a time for building rather than designing) are related to developer ergonomics in some form.

pornel 9y ago

As someone who's been using Rust in production for over a year, and C on and off for 17 years, I can assure you Rust really delivers what it promises. The challenges are not exaggerated, but they do have solutions, so they're not deal-breakers in practice. The learning curve is steep. It takes effort, but once you get it (and unlearn some C-isms), Rust is a quite productive language. Some patters and data structures are not understood by borrow checker, so you have to fall back to coding as-safely-as-any-C program. However, thanks to the practice of wrapping risky bits in safe abstractions, they remain only a small fraction of any program. It might feel that writing any "unsafe" code defeats the promise of Rust, but it doesn't. The concept of safe abstraction is quite powerful, and makes sense even for wrapping 100% C libraries, where you can encode informal constraints form the manual as code, and automatically prevent library API from being misused.