6 ms·

> Rust is much easier to teach than C or C++, Not sure about that. If you know C, which is easy to learn, you already know a lot about C++, or at least the pa

• steveklabnik 9y ago
  Many Rust programmers never learned C, or have only a cursory understanding of it. Most C++ people I talk to would strongly disagree that in C++, you should do things the C way.
  • pjmlp 9y ago
    The C way in C++ should only be used the same way as unsafe in Rust. Very well hidden in safe abstractions, and validated by a profiler that they are actually better than the safer C++ alternatives.
  • renox 9y ago
    Yes and no: when you want to do real-time programming (either no allocation or allocation only during an 'initialisation' phase) using C++ like a better C is a good idea IMHO.
• Tade0 9y ago
  As someone who's field is front-end development I have to say that among those three Rust was the easiest to learn - mostly because the compiler helps you understand what's wrong. C seems easy at first glance, but has so much manual work(managing memory, dependencies) that working with it is to me - well - tedious.
• anderspitman 9y ago
  Have you heavily used C++11 or newer on a "modern" codebase? I consider myself a more than competent C programmer but the complexity of modern C++ is non-trivial in my opinion.
• vvanders 9y ago
  > If you know C, which is easy to learn, you already know a lot about C++ Not sure I'd agree. If you know C you know a very small subset of C++(and growing smaller with each revision). Things like move semantics, exceptions + constructors, lambdas and templates are huge and each one can easily be as complex as straight C99.
• zlynx 9y ago
  C appears easy to learn. C++ a bit harder, but learnable. What isn't easy to learn is all the horrible ways C is broken. Don't return addresses to local variables. Remember realloc can change the location pointer. Don't use the C string functions. C++ adds fun gotchas like using the c_str() of a temporary string object. Carelessly passing local objects by reference to a lambda thread function. All of the amusingly horrible ways to screw up data structures using shared_ptr and enable_shared_from_this. Better yet, linking C or C++ objects together that have been compiled with different "#defines" set so the structs, objects and vtables are different sizes. C is not easy to learn.
  • jokoon 9y ago
    C is just some readable assembly. If you tell a computer to crash into a wall, it will crash into a wall. That is the best lesson you can teach a student. It is great to have a language that teaches you to write better code. Failure is a good teacher too. If you tell a student to follow some rules without telling him why those rules exist, it is not always a good idea. It is an awesome idea to have the safest code, but not necessarily a good idea to teach programming using safety rules.
    • oconnor663 9y ago
      > C is just some readable assembly. Here's one article that argues the other side. I like this part a lot, though the wording is a maybe a little bit argumentative :) "Be knowledgeable about what’s actually in the C and C++ standards since these are what compiler writers are going by. Avoid repeating tired maxims like “C is a portable assembly language” and “trust the programmer.” Unfortunately, C and C++ are mostly taught the old way, as if programming in them isn’t like walking in a minefield. Nor have the books about C and C++ caught up with the current reality. These things must change." https://blog.regehr.org/archives/1520 https://blog.regehr.org/archives/1520
      • jokoon 9y ago
        I said it's readable, but it's just some simple translation. C still has all the issues of having to write assembly, so a C programmer should have to check if its C code is not doing anything unsafe, like an ASM developer would. Programming is not easy, and it always has been a minefield. You cannot write good code quickly. Even learning rust will have a cost, although it's a worthy cost. Writing unsafe code is cheap and was often a good enough solution.
• pcwalton 9y ago
  That doesn't square with my experience. I've taught beginning programmers more or less the "C subset" of C++, and it was a nightmare. The biggest problem is that when they inevitably hit undefined behavior, there is no easy way to learn what is wrong. The program hits a segfault or prints garbage on the screen—where to begin? I instinctively know what is likely to be wrong, but that's only through years of experience; it's almost impossible to teach that quickly. Even if, by luck, the program segfaults instead of silently corrupting memory, the line number where the failure occurred doesn't necessarily correspond to what is wrong—often the problem occurred earlier. Rust is in a much better position here, since the compiler can actually isolate precisely what is wrong in those cases and emit diagnostics at the exact location where the problem occurred. That's much easier to teach.
  • naasking 9y ago
    Learning C via an interpreter that errors out on undefined behaviour seems like a good way to address those issues. Not sure if any of the interpreters I've seen over the years actually does this though, though I imagine altering something like PicoC would be straightforward enough.
    • pcwalton 9y ago
      Judging by the development of UBSan and ASan, I think such a thing would be anything but straightforward, even with a simple C compiler.
• pohl 9y ago
  It really depends on where you're coming from. I had no difficulties learning Rust, but I already knew Swift pretty well.
• sidlls 9y ago
  I have lots of experience with C++, and a non-trivial amount with C. I've done everything from game development to writing drivers to scientific computing with these languages. Here's how I describe it: a good portion of the stuff C and C++ programmers learn with experience (e.g. best practices, memory management, etc.) are "front loaded" in Rust by having to learn about Borrowing, lifetimes and the like. One isn't harder than the other, but the path to proficiency is quite different. In my view Rust has a superior path.