4 ms·

I think you make an excellent point that this is a poor demonstration if one is trying to convince a decent C++ programmer to try Rust. Many of these issues ar

by steego 12y ago

I think you make an excellent point that this is a poor demonstration if one is trying to convince a decent C++ programmer to try Rust. Many of these issues are simply not a problem for moderately disciplined C++ programmers. If anything, this sort of post is more convincing to a junior developer who wants their compilers to do more to warn them when they've done something stupid. They want to write idiomatic C++, but they're lazy and inexperienced, so if there's a language where the compiler provides feedback when they deviate from what's idiomatic, they're going to opt for the feedback. I'd be very interested in what's drawn you into trying Rust and what you think are the most redeemable qualities.

danieljh 12y ago
I'm trying Rust for the same reason why I'm investing weeks into learning Clojure. Because I'm convinced learning more approaches to high-level problems (like ownership, concurrency, typing, patterns) is one way to improve my overall skill set and thinking. One thing I like about Rust is how you e.g. can specify a Sortable trait and then with T: Sortable require it for types. This will eventually come to C++ with Concepts (lite), for now there are ways to work around this, e.g. with: #define requires(...) typename enable_if<(__VA_ARGS__), int>::type = 0 template <typename T, requires(is_integral<T>())> void fn(T); Without a feature like this you may see cryptic errors from inside template instantiations coming from your stdlib, when you try to sort something that is not sortable.
CountSessine 12y ago
I agree completely. None of these examples are going to convince a C++ programmer who's already sunken the cost of learning the language to switch to rust. Something I realized at some point is that these "language A vs language B" comparisons aren't really there to convince adherents of language B to switch to language A. You'll see lots of comparisons on the web of Haskell/Scheme/Lisp/C#/F#/Ocaml etc put up against really poorly written C/C++ code, with "language A" inevitably coming out of the comparison pretty well. Thinking back to my days at school, a lot of physicists were telling each other that if they wanted their simulations to run in a reasonable amount of time, they had to code them in C. These comparisons are really aimed at them - the message here is, "yes, a really great C programmer could write machine-optimal FFTs or whatever in C, but the code that you, a beginner, will end up writing could actually end up being not much faster and in some cases perhaps even a lot slower than the equivalent code in Haskell/etc".
- im2w1l 12y ago
  Nowadays you would compute the FFT's on a GPU. And it does really matter.
burntsushi 12y ago
> If anything, this sort of post is more convincing to a junior developer who wants their compilers to do more to warn them when they've done something stupid. They want to write idiomatic C++, but they're lazy and inexperienced, so if there's a language where the compiler provides feedback when they deviate from what's idiomatic, they're going to opt for the feedback. Compile time checking attracts more than just the lazy and inexperienced. (Maybe you didn't mean to imply otherwise, but it sure as hell reads that way.)
- steego 12y ago
  I didn't. I was describing what makes it attractive to newer developers with limited C++ experience. I'm sure it's also attractive to some experienced C++ developers who have grown tired of C++'s shit. I personally find C++ is fine and dandy if you're working with a disciplined team. On the other hand, it's bad qualities are immensely magnified when the overall team lacks in talent and/or experience.
  - oldmanjay 12y ago
    Not all of us who are unwilling to deal with the decades of bad language design C++ displays feel this way because we lack talent and experience.
    - steego 12y ago
      I'm always surprised when programmers confuse unidirectional implication with bidirectional implication. I'm only making a comment that alternatives to C++ are really good at attracting people who never developed the discipline required to write good C++. Experienced and talented C++ developers don't really have C++ problems, so most articles trying to lure them away with promises of memory safety using contrived examples will fall on deaf ears. I know many good and experienced programmers with former C++ experience who detest it. Personally speaking, I'm an average but fairly experienced programmer, so I tend to prefer tools that help me catch my mistakes so I can focus on solving problems cleanly.

by steego 12y ago

danieljh 12y ago

I'm trying Rust for the same reason why I'm investing weeks into learning Clojure. Because I'm convinced learning more approaches to high-level problems (like ownership, concurrency, typing, patterns) is one way to improve my overall skill set and thinking. One thing I like about Rust is how you e.g. can specify a Sortable trait and then with T: Sortable require it for types. This will eventually come to C++ with Concepts (lite), for now there are ways to work around this, e.g. with: #define requires(...) typename enable_if<(__VA_ARGS__), int>::type = 0 template <typename T, requires(is_integral<T>())> void fn(T); Without a feature like this you may see cryptic errors from inside template instantiations coming from your stdlib, when you try to sort something that is not sortable.

CountSessine 12y ago

I agree completely. None of these examples are going to convince a C++ programmer who's already sunken the cost of learning the language to switch to rust. Something I realized at some point is that these "language A vs language B" comparisons aren't really there to convince adherents of language B to switch to language A. You'll see lots of comparisons on the web of Haskell/Scheme/Lisp/C#/F#/Ocaml etc put up against really poorly written C/C++ code, with "language A" inevitably coming out of the comparison pretty well. Thinking back to my days at school, a lot of physicists were telling each other that if they wanted their simulations to run in a reasonable amount of time, they had to code them in C. These comparisons are really aimed at them - the message here is, "yes, a really great C programmer could write machine-optimal FFTs or whatever in C, but the code that you, a beginner, will end up writing could actually end up being not much faster and in some cases perhaps even a lot slower than the equivalent code in Haskell/etc".

im2w1l 12y ago
Nowadays you would compute the FFT's on a GPU. And it does really matter.

burntsushi 12y ago

> If anything, this sort of post is more convincing to a junior developer who wants their compilers to do more to warn them when they've done something stupid. They want to write idiomatic C++, but they're lazy and inexperienced, so if there's a language where the compiler provides feedback when they deviate from what's idiomatic, they're going to opt for the feedback. Compile time checking attracts more than just the lazy and inexperienced. (Maybe you didn't mean to imply otherwise, but it sure as hell reads that way.)

steego 12y ago
I didn't. I was describing what makes it attractive to newer developers with limited C++ experience. I'm sure it's also attractive to some experienced C++ developers who have grown tired of C++'s shit. I personally find C++ is fine and dandy if you're working with a disciplined team. On the other hand, it's bad qualities are immensely magnified when the overall team lacks in talent and/or experience.
- oldmanjay 12y ago
  Not all of us who are unwilling to deal with the decades of bad language design C++ displays feel this way because we lack talent and experience.
  - steego 12y ago
    I'm always surprised when programmers confuse unidirectional implication with bidirectional implication. I'm only making a comment that alternatives to C++ are really good at attracting people who never developed the discipline required to write good C++. Experienced and talented C++ developers don't really have C++ problems, so most articles trying to lure them away with promises of memory safety using contrived examples will fall on deaf ears. I know many good and experienced programmers with former C++ experience who detest it. Personally speaking, I'm an average but fairly experienced programmer, so I tend to prefer tools that help me catch my mistakes so I can focus on solving problems cleanly.