Hacker News Reader

Comment by steego | Hacker News Reader

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.

View on HN

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.

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

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

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

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.

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.

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.

Experienced and talented C++ developers have C++ problems all the time. Or maybe these core dumps I deal with in my day job are all in my imagination...

Reply on news.ycombinator.com