Python is memory safe? Can’t you access/address memory with C bindings?

  • Dark Arc
    link
    fedilink
    English
    1108 months ago

    Python is memory safe? Can’t you access/address memory with C bindings?

    You can do that in basically any language. Rust even has the ability to break out of its safeguards and write unsafe Rust code.

    “Memory safety” in this context is more about the defaults and how easy it is to write unsafe code accidentally.

    • GroteStreet 🦘
      link
      fedilink
      English
      328 months ago

      Obligatory link to the Rustonomicon.

      Should you wish a long and happy career of writing Rust programs, you should turn back now and forget you ever saw this book.

    • Traister101
      link
      fedilink
      318 months ago

      Unsafe Rust really just let’s you play with pointers

      This is the entirety of what Unsafe Rust allows

      • Dereference a raw pointer
      • Call an unsafe function or method
      • Access or modify a mutable static variable
      • Implement an unsafe trait
      • Access fields of unions
      • Ryan
        link
        fedilink
        English
        17
        edit-2
        8 months ago

        I’m still onboard with rust as being better than C, however…

        My understanding is that it is considerably harder to correctly write unsafe rust than it is to correctly write c, because if you accidentally violate any of safe rust’s guaranteed invariants in an unsafe block, things go bananas.

        • @BatmanAoD@programming.dev
          link
          fedilink
          228 months ago

          That’s true in C as well, though. This is what people mean when they say things like “undefined behavior can result in time travel”.

          The difference is twofold:

          • Rust’s rules for valid unsafe code are not completely formalized yet. This means that there are open questions about whether particularly complex patterns in unsafe code will be guaranteed by future versions of the compiler to be sound. Conversely, the C and C++ spec are generally sufficient to determine whether any particular piece of code has undefined behavior, even if actually analyzing it to find out is not possible automatically using existing static analysis tools.
          • Because safe Rust is so strict about what it permits, the compiler is able to make more aggressive optimizations; in theory, this could indeed cause undefined behavior to be “worse” at runtime than a comparable situation in a globally-unsafe language. I’m unaware of any actual examples of that phenomenon, though.
        • Traister101
          link
          fedilink
          10
          edit-2
          8 months ago

          Yes Rust is harder to write than C, that’s basically by design as it’s due to the statically guaranteed memory safety. That’s pretty magical. C doesn’t have that and neither does C++ even with smart pointers and such. Rusts unsafe keyword is poorly named, what it actually does is tell the compiler that you the programmer guarantee Rusts rules are upheld within the unsafe block.

          For example

          Access or modify a mutable static variable

          That is a global, that’s incredibly hard to impossible to statically prove it’s safely done, so you have to do it in an unsafe block. So you violating Rusts rules within an unsafe block is actually using the unsafe block wrong. That’s not what it’s for

          • @Solemarc@lemmy.world
            link
            fedilink
            2
            edit-2
            8 months ago

            I remember watching a video of someone writing C code and making the same thing in unsafe rust. While the C code worked just fine the rust code had UB in it and was compiled to a different set of instructions.

            Unsafe rust expects you to uphold the same guarantees that normal rust does and so the compiler will make all the same optimisations it would if the code wasn’t unsafe and this caused UB in the example rust code when optimised for performance. It worked just fine on the debug build, but that’s UB for you.

          • @Fal
            link
            fedilink
            English
            08 months ago

            Yes Rust is harder to write than C

            I would totally argue with this. Rust is way easier to write than C

            • Traister101
              link
              fedilink
              28 months ago

              I’d probably say it depends but I’m no Rust expert and I have no direct experience with C (though quite familiar with C++).

              Basically I’d expect writing C to be easy, but not safe. IE you can quickly and easily write C that compiles but has runtime issues. Rust for the most part will catch everything but logic issues during/before compilation meaning once the program runs you’ll have very high confidence in it’s runtime behavior leading to time spent “fighting the compiler” instead of figuring out wtf is going wrong at runtime.

              • Traister101
                link
                fedilink
                28 months ago

                I think primarily I don’t really care to argue about if it’s harder to write or not since it doesn’t really matter. I think the pros Rust provides are worth all it’s cons

              • @Fal
                link
                fedilink
                English
                -28 months ago

                IE you can quickly and easily write C that compiles but has runtime issues.

                So what’s “easy” about it then? Just getting something to compile? That’s not a very good measure of “easyness”.

            • @vext01@lemmy.sdf.org
              link
              fedilink
              28 months ago

              I agree for the most part, but writing data structures with shared mutable state can be a total pain in Rust.

              • @Fal
                link
                fedilink
                English
                -18 months ago

                How so? That’s like, the thing that makes rust awesome to write.

                • @vext01@lemmy.sdf.org
                  link
                  fedilink
                  18 months ago

                  It’s hard to get those kinds of data structures through the borrow checker.

                  Try writing a doubly linked list.

        • Tobias Hunger
          link
          fedilink
          88 months ago

          That depends a lot on how you define “correct C”.

          It is harder to write rust code than C code that the compiler will accept. It is IMHO easier to write rust code than to write correct C code, in the sense it only uses well defined constructs defined in the C standard.

          The difference is that the rust compiler is much stricter, so you need to know a lot about details in the memory model, etc. to get your code past the compiler. In C you need the same knowledge to debug the program later.

      • Dark Arc
        link
        fedilink
        English
        48 months ago

        And what does that exclude that C or C++ has that’s memory unsafe? I suppose use after free?

        Dereference a pointer without a bounds check is the major problem when we’re talking about memory safety.

        Accessing a union that’s in an invalid state is also a big problem.

        Use after free… Maybe?

        Thread safe code isn’t the issue otherwise Java, Python, etc would all be on the list of languages to run from.

        Point being, that is still a very dangerous subset. Off-by one errors have done in a lot of C code (and C++ code that isn’t using range-based loops).

        A lot of these issues can be avoided in C++ by just using existing types like std::variant, std::unique_ptr, std::shared_ptr, std::array, and std::vector (with the at based accessor) instead of lower level constructs.

        • Traister101
          link
          fedilink
          6
          edit-2
          8 months ago

          What Rust provides is statically guaranteed memory safety. Some C++ types will prevent memory issues however the language itself is unsafe. Playing with raw pointers is just as valid as using std::unique_ptr. In Rust however you must sign a contact (using unsafe) in order to play with raw pointers. Unsafe is you the programmer promising that you followed the rules. This is like how C++ says it’s illegal to write UB and your program will break (and it’s your fault) but enforced through a special type of block

          • Dark Arc
            link
            fedilink
            English
            78 months ago

            In Rust however you must sign a contact (using unsafe) in order to play with raw pointers. Unsafe is you the programmer promising that you followed the rules. This is like how C++ says it’s illegal to write UB and your program will break (and it’s your fault) but enforced through a special type of block

            Which is what I said, this is about the default.

            My issue is not that I don’t understand Rust provides static guarantees. My issue is that you raised a comparison between unsafe Rust and C++ code. In that comparison, you’re basically saying “writing an entire program in a rust unsafe block would be better than writing an entire program in C++” and I think that is very wrong.

            Rust unsafe is not better than normal C++ while following best practices for maintaining memory safety.

            • @arendjr@programming.dev
              link
              fedilink
              48 months ago

              I wouldn’t be so sure myself. Even unsafe Rust still uses the borrow checker, for instance. And you still get stricter checks around overflows and such as well. What unsafe does is that it unlocks the ability to use raw pointers and call other unsafe functions (among a few other things), but importantly it doesn’t disable the safety features that Rust has built-in. While unsafe Rust does indeed have some gotchas on its own, I think in general you’re still better off even with unsafe Rust than with C++.

        • @arendjr@programming.dev
          link
          fedilink
          5
          edit-2
          8 months ago

          I would still like to take a moment to answer your specific questions more directly:

          And what does that exclude that C or C++ has that’s memory unsafe? I suppose use after free?

          I think indeed use after free is the main one, although data races are another. Both are prevented in Rust by the borrow checker.

          Dereference a pointer without a bounds check is the major problem when we’re talking about memory safety.

          I think that’s only half of the issue, with the other half indeed being use after free. After all, using a reference isn’t much different from dereferencing a pointer. But doing bounds check on all your pointers is relatively easy to do by humans; you see where the pointer is being used and you see if there’s a check or not. But proving liveness of your references before you use them is much harder, because it often requires whole-program analysis to understand when the target may be destroyed. And in terms of danger, use after free is just as dangerous as unbound pointer access.

          Thread safe code isn’t the issue otherwise Java, Python, etc would all be on the list of languages to run from.

          Thread safe code is also the issue. The reason people don’t have to run from Java is because data races there don’t escalate to memory unsafety; they’re just caught as “ordinary” exceptions and thus manifest as ordinary (but still hard-to-debug) bugs. But in C++ those too can create invalid memory accesses, with a possibility for exploitation. In fact, even Go has a memory unsafe data race in its threading model that occurs because of its use of fat pointers that embed both a data type and an address.

          Point being, that is still a very dangerous subset. Off-by one errors have done in a lot of C code (and C++ code that isn’t using range-based loops).

          It is indeed a dangerous subset, but as I mentioned elsewhere, Rust’s borrow-checker, which prevents use after free with references is still active, even in unsafe code. Off-by-one errors are still bound-checked even in unsafe code, unless you explicitly use the non-bound-checked versions. Any Rust code that is valid safe Rust is just as safe when wrapped in an unsafe block. It is only when you explicitly use the unsafe features that you’re on your own when it comes to safety.

          A lot of these issues can be avoided in C++ by just using existing types like std::variant, std::unique_ptr, std::shared_ptr, std::array, and std::vector (with the at based accessor) instead of lower level constructs.

          They indeed avoid some of the issues, but notably don’t protect against use after free at all. And take std::vector as an example:

          std::vector v;
          v[2]; // out-of-bounds access
          

          vs.

          unsafe {
              let v = Vec::new();
              v[2]; // panic
          }
          

          Even wrapped in unsafe, the Rust equivalents are still safer.

  • @onlinepersona@programming.dev
    link
    fedilink
    English
    578 months ago

    Mr Stroustrup can spin it however he likes, but 70% of CVEs are caused by memory errors in unsafe languages like C and C++. That isn’t happening because the majority of their devs are idiots. The language is the problem.

    Talking about “but there are tools” and “hold on a minute, there a ways to write safe C++” is missing. It’s way too easy to write memory unsafe code in C++. The opposite is true of other languages and that’s why they are being recommended (dare I say pushed) over C++. To write memory unsafe Rust for example, you really, really have to want to.

    C++ is his baby, Of course he won’t acknowledge it and it was entirely predictable he would blame the programmers. The language will be the equivalent of COBOL in a decade or two.

    CC BY-NC-SA 4.0

    • @Technus@lemmy.zip
      link
      fedilink
      368 months ago

      If “just don’t be an idiot” worked in the real world we wouldn’t have any need for laws or safety regulations or certifications. It’s not and never has been a compelling argument.

      Writing C++ is like walking around a construction site without a hard hat and going “ah I don’t need it, I’ll just make sure nothing falls on my head.” Yeah sure, buddy, we’ll make sure that’s written on your tombstone.

      • Black616Angel
        link
        fedilink
        228 months ago

        Yes, right. We could completely erase one third of exploitable vulnerabilities (by your numbers) only by switching to modern languages.

        There is no good argument against that. Why wait for C or C++ to try and implement get another weird “solution” for those problems? (That no one uses then anyway)

  • @Feathercrown@lemmy.world
    link
    fedilink
    English
    49
    edit-2
    8 months ago

    $100 says his response boils down to “just don’t write unsafe code”

    Edit: It did. He also said C++ is working to implement optional safety features, but tl;dr:

    Of the billions of lines of C++, few completely follow modern guidelines

    And the modern guidelines are mostly an unenforced list of things not to do.

    • @porgamrer@programming.dev
      link
      fedilink
      198 months ago

      Even following the guidelines, modern C++ is just a huge pile of half-finished ideas. It goes pretty well for the first few hundred lines of code, and then you hit a very basic problem where the solution is “yes this will work great in C++26, if the proposal doesn’t get delayed again”.

      • @lysdexic@programming.dev
        link
        fedilink
        English
        -58 months ago

        Even following the guidelines, modern C++ is just a huge pile of half-finished ideas.

        You’re making it pretty clear that you are completely oblivious to what C++ is, what are the differences between C++ versions, and what are the real world issues solved by each new version.

        I would ask you to clarify your persona clams by providing a concrete example to back each of your statements, but I know you have none.

        • @porgamrer@programming.dev
          link
          fedilink
          48 months ago

          Lol okay. Here are some concrete examples I don’t have:

          Templates as basic generics

          • Templates still show bizarre error messages far too deep into instantiation, despite at least three major features which provided opportunities to fix the problem (static_assert, type_traits, and then concepts)

          Templates for metaprogramming

          • 33 years after the introduction of templates, there are still many common cases in which the only good way to abstract a pattern is by using a macro, and many cases that neither macros or templates can solve
          • There is finally an accepted proposal to fix part of the problem, which will be introduced in C++26, and probably not usable in real code until 2030 at the earliest
          • In 2035, people will still be reluctantly using string macros and external code generation to solve basic problems in C++

          Safe union types

          • C++17, std::variant was introduced to provide a safe inline union type
          • The main API for accessing it is inexplicably slow, unlike in every competing language
          • The fast alternative is an eyesore that can’t integrate with switch statements except via weird, unmaintainable hacks
          • Everyone keeps using custom struct/union/enum combos instead
          • CVEs everywhere

          Error handling

          • C++ uses exceptions as the primary error handling mechanism
          • Exceptions are so slow and so riddled with problems that some companies ban them, and almost all consider them bad practice for representing common failure paths (e.g. failing to parse something)
          • std::expected eventually approved, similar to Rust’s Result type, but with no equivalent to the ‘?’ operator to make the code readable
          • Now there is a proposal to introduce “value type exceptions” instead, which is gathering momentum before std::expected has even stabilised, but will probably not be available for 10 years

          Subtype polymorphism deprecated

          • Now that virtual methods and inheritance are widely considered tools of last resort, they obstruct the introduction of better alternatives
          • Instead we have widespread use of specialised template structs and CRTP to replace instance inheritance with a kind of static inheritance designed for templates
          • It’s all a hack, and as a result it’s full of edge cases that don’t work very well, and poor tool support

          References

          • Good C++ programmers use references where possible, because pointers can be null
          • Good C++ programmers avoid unnecessary copies and allocations
          • Good C++ programmers avoid patterns that can permit unintended coercions with no error
          • Oh no, I accidentally assigned a reference to an auto variable in a template, and instead of giving a helpful type error it implicitly coerced a new copy of my vast memory buffer into existence
          • Okay fine I’ll pass pointers to avoid this, and just trust they won’t be null
          • Oh no, C++ has standardised the idea that raw pointers represent nullability even in all their newest standard library types (thanks again, std::variant)
        • @orangeboats@lemmy.world
          link
          fedilink
          28 months ago

          I think if you consider anything post C++03 (so C++11 or newer) to be “modern C++” then Concepts must be the top example, doesn’t it?

          Counting from C++0x that’s almost a decade of waiting.

    • Oliver Lowe
      link
      fedilink
      88 months ago

      $100 says his response boils down to “just don’t write unsafe code”

      Edit: It did. He also said C++ is working to implement optional safety features, but tl;dr:

      Of the billions of lines of C++, few completely follow modern guidelines

      Pretty sure this is a No true Scotsman moment. (I’ve always wanted to bring this fallacy up but I never knew when lol)

  • @litchralee@sh.itjust.works
    link
    fedilink
    English
    388 months ago

    I’m not a Rust developer (yet), but I understand its strength in this regard as: Rust is statically memory safe by default, and code which isn’t statically memory safe must be declared with the unsafe keyword. Whereas C++ has not deprecated C-style pointers, and so a C engineer can easily write unsafe C code that’s valid in a C++ compiler, and no declaration of its unsafeness is readily apparent to trigger an audit.

    It’s nice and all that C++ pioneered a fair number of memory safety techniques like SBRM, but the debate now is about safety by default, not optional bolt-on safety. All agree that the overall process to achieve correct code is paramount, not just the language constructs.

    • snoweM
      link
      fedilink
      388 months ago

      It’s also just a huge fallacy. He’s saying that people just choose to not write memory safe code, not that writing memory safe code in C/C++ is almost impossible. Just look at NASA’s manual for writing safe C++ code. It’s insanity. No one except them can write code that’s safe and they’ve stripped out half the language to do so. No matter how hard you try, you’re going to let memory bugs through with C/C++, while Rust and other memory safe languages have all but nullified a lot of that.

      • @MajorasMaskForever@lemmy.world
        link
        fedilink
        English
        21
        edit-2
        8 months ago

        As someone who is in the aerospace industry and has dealt with safety critical code with NASA oversight, it’s a little disingenuous to pin NASA’s coding standards entirely on attempting to make things memory safe. It’s part of it, yeah, but it’s a very small part. There are a ton of other things that NASA is trying to protect for.

        Plus, Rust doesn’t solve the underlying problem that NASA is looking to prevent in banning the C++ standard library. Part of it is DO-178 compliance (or lack thereof) the other part is that dynamic memory has the potential to cause all sorts of problems on resource constrained embedded systems. Statically analyzing dynamic memory usage is virtually impossible, testing for it gets cost prohibitive real quick, it’s just easier to blanket statement ban the STL.

        Also, writing memory safe code honestly isn’t that hard. It just requires a different approach to problem solving, that just like any other design pattern, once you learn and get used to it, is easy.

        • snoweM
          link
          fedilink
          18 months ago

          Also, writing memory safe code honestly isn’t that hard. It just requires a different approach to problem solving, that just like any other design pattern, once you learn and get used to it, is easy.

          the CVE list would disagree with you.

        • @0x0@programming.dev
          link
          fedilink
          18 months ago

          I’d’ve thought Ada would play a larger role in aerospace, because of these issues, among others.

        • @arendjr@programming.dev
          link
          fedilink
          -28 months ago

          Also, writing memory safe code honestly isn’t that hard. It just requires a different approach to problem solving, that just like any other design pattern, once you learn and get used to it, is easy.

          This statement is kinda ironic after you just said it’s “easier” to just ban the entire STL and dynamic memory allocation as a whole. You already left the domain of what most consider “easy” quite a while ago.

      • @zik@lemmy.world
        link
        fedilink
        1
        edit-2
        8 months ago

        It’s also a fallacy that rust code is memory safe. I audited a couple of large rust projects and found that they both had tens of unsafe constructs. I presume other projects are similar.

        You can’t use “unsafe” and then claim that your program’s memory safe. It may be “somewhat safe-ish” but claiming that your code is safe because you carefully reviewed your unsafe sections leaves you on the same shaky ground as c++, where they also claim that they carefully review their code.

        • @calcopiritus@lemmy.world
          link
          fedilink
          28 months ago

          I don’t have the data, but I don’t think it’s wild to assume that most rust programs have 0-1 unsafe blocks, in total. Except for special cases like ffi.

          Even if your rust project has 1000s of unsafe blocks, it is still safer than C++, which is 100% an unsafe block. You only have to carefully review the parts marked “unsafe”, in C++ you have to carefully review the whole code.

          Also, because unsafe blocks are explicitly declared, you know which parts of the code require extra carefulness, and if you encounter a memory bug, doing Ctrl+F “unsafe” will soon show the root cause.

  • Why wait and hope for C++ to get where modern languages are now? I know there’s value in the shared experience in C++ that if adapted would make it stronger, but I can only see a development of C++ having to force a drop of a lot of outdated stuff to even get started on being more suitable.

    But the language is just not comfortable to me. From large amounts of anything creating undefined behavior, the god awful header files which I hate with a passion, tough error messages and such. I also met a fun collision of C++ in Visual Studio and using it with CMake in CLion.

    I’ve just started looking at rust for fun, and outside not understanding all the errors messages with the bounded stuff yet, figuring out what type of string I should use or pass, and the slow climb up the skill curve, it’s pretty nice. Installing stuff is as easy as copy pasting the name into the cargo file!

    Rust is just the prospective replacement of C++ though, people act like the White house said that C++ should be replaced by rust now. But the just recommend it and other languages, C# will do for a lot of people that does not need the performance and detail that the aforementioned languages target. Python is targeting a whole different use, but often combined with the faster ones.

    C++ will live a long time, and if the popularity dies down it will surely be very profitable to be a developer on the critical systems that use it many years from now. I just don’t think an evolution of C++ is going to bring what the world needs, particularly because of the large amount of existing memory related security vulnerabilities. If things were good as they are now, this recommendation would not be made to begin with.

    • @arendjr@programming.dev
      link
      fedilink
      158 months ago

      I totally agree with this comment, and on top of that I would recommend anyone who really cares about the current state of affairs regarding safety in C++ to read this overview: https://accu.org/journals/overload/32/179/teodorescu/

      Quote:

      Personally, I am not convinced that in the near future, C++ can do something to stop this trend. C++ will leak talent to other languages (currently Rust, but perhaps in the future to Cppfront, Carbon, Hylo or Swift). If the progress towards safety started in 2015 as Bjarne suggested, the last 8 years have seen very little progress in safety improvements. Even with accelerated efforts, the three-year release cycle and slow adoption of new standards will keep C++ a decade away from addressing major safety concerns.

  • @merthyr1831@lemmy.world
    link
    fedilink
    328 months ago

    He can get mad all he likes but there’s a reason the Linux kernel’s experiment with rust is going much smoother than C++ (which only lasted a literal week btw)

  • @_dev_null@lemmy.zxcvn.xyz
    link
    fedilink
    288 months ago

    Biden administration seems oblivious of the strengths of contemporary C++

    Well ok, but the concern is about the weaknesses, Mr. Stroustrup.

    • NostraDavid
      link
      fedilink
      5
      edit-2
      8 months ago

      Stroustrup to congress: “You expect me to talk?”
      Congress: “No, Mr Stroustup, we expect your language to DIE!”

    • @lysdexic@programming.dev
      link
      fedilink
      English
      18 months ago

      Well ok, but the concern is about the weaknesses, Mr. Stroustrup.

      I don’t think these discussions on “weaknesses” come from a place of intelectual honesty. None of these arguments even touches the fact that there are already a myriad of freely available static code analysis tools and memory profilers that do a very good job catching memory safety issues.

      For some unexplainable reason, these criticisms of C++ always focus on a single strawman: these tools do not exist and no developer in the world cares about the topic.

      • There is a lot of fanboying in discussions like these, so I understand if you’re weary of that. That said I don’t think static analysis tools are a very good point of comparison for (what I’m assuming that you’re referring to) Rusts ownership system.

        While static analysis tools certainly can be useful for some classes of errors, there are types of errors that they can’t catch that the borrowchecker can. This is because the language are built around them in Rust. Rusts lifetime analysis is dependent on the user adding lifetime annotations in certain situations, so since c++ doesn’t have these annotations static analysis tools for c++ can’t benefit from the information these annotations provide.

        Furthermore, c++ suffers from being an old language with a lot of features. Legacy features can allow for various loopholes that are hard for a static analysis tool to reason about.

        C++ static analysis tools can find errors, but Rusts borrowchecker can prove the absence of errors modulo unsafe code.

        That said, I don’t have any good data on how much of a problem this is in practice. Modern c++ with a CI-pipeline doing static analysis and forbidding certain footguns is safe enough for most contexts. Personally, I’m exited about Rust more because I think that it’s a nicely designed language than because of its safety guarantees, but it doesn’t really have the ecosystem support for a lot of things, like gamedev or ui at the moment.

      • @Lmaydev@programming.dev
        link
        fedilink
        3
        edit-2
        8 months ago

        A huge number of exploits rely on unsafe memory bugs.

        The fact you have to rely on external tools to manage these issues perfectly illustrates that the language is not memory safe without extra work and it’s easy to miss things.

        It seems much more sensible to just use a language that is.

      • @_dev_null@lemmy.zxcvn.xyz
        link
        fedilink
        28 months ago

        a single strawman: these tools do not exist and no developer in the world cares about the topic

        I haven’t seen anyone make the argument that denies these things exist - it’s that the existence of these tools are even necessary to safeguard the language in the first place is the argument. And then on top of that, you’ll additionally need a shop that is even allowed the time to properly utilize these tools and implement their usage as standard practice within the company culture.

        That there are alternatives which remove (significantly more) footguns is the overall point. Work in one of these other languages so e.g. dumb-ass PMs don’t even have the option of pilfering the time it takes to code safely, as it would already be baked in.

  • I’d love to see Bjarne Stroustrup being grilled by Congress about this, and have to explain shared pointers and reference counting to the same people who didn’t understand how Facebook made money.

  • Rikj000
    link
    fedilink
    English
    12
    edit-2
    8 months ago

    TLDR: But-hurt C++ dev has a hard time accepting that his favorite language is not memory safe.

    • Dark Arc
      link
      fedilink
      English
      158 months ago

      C++ is leagues above C in this regard. He’s rightly upset that they’re lumping the two together.

      Bjarne’s work for safety profiles could indeed manifest in a solution that guarantees memory safety; time will tell. C++ is a moving target.

      • @marcos@lemmy.world
        link
        fedilink
        138 months ago

        C++ is leagues above C in this regard.

        It’s really not. It has the same flaws, some libraries that promise to avoid them (as long as you don’t hold them wrong - what every single programmer does), and lots and lots of new flaws that may come from anywhere.

        • @vext01@lemmy.sdf.org
          link
          fedilink
          38 months ago

          I use C, C++ and Rust in my dayjob.

          I don’t like C++, but I disagree with your statement.

          C++ has:

          • a string type, which sidesteps error prone buffer juggling.
          • smart pointers for scope based deallocation.
          • generic data types. No more hand rolling list and mapping types with void *.

          It’s obviously still not a fully memory safe language, but it has some perks over C. I’d still much rather be using rust (most of the time).

      • Tobias Hunger
        link
        fedilink
        9
        edit-2
        8 months ago

        That depends on how you decide which bucket something gets thrown into.

        The C++ community values things like the RAII and other features that developers can use to prevent classes of bugs. When that is you yard-stick, then C and C++ are not in one bucket.

        These papers are about memory safety guarantees and not much else. C and C++ are firmly in the same bucket according to this metric. So they get grouped together in these papers.

  • Gaia [She/Her]
    link
    fedilink
    108 months ago

    Sounds like he’s just mad something he made is being replaced with something that is better in every conceivable way

    Sorry bud but most people are focusing on rust, not python, and you’ve been lapped by them several times over.

    • I’m just a modder and primarily use C, but started with BASIC and then C++; I am curious, without knowing anything other than the name and it’s apparent growing popularity: What makes Rust so appealing? And if I was interested in trying to learn Python again, would it be better to just learn Rust instead?

      • @lordmauve@programming.dev
        link
        fedilink
        38 months ago

        Rust has a lot going for it beyond just the safety thing: excellent package manager, powerful trait system and generics, helpful compiler errors.

        The whole language is designed to help you avoid making the programming mistakes people tend to make, not just the borrow checker and memory safety.

      • Gaia [She/Her]
        link
        fedilink
        38 months ago

        I guess I kind of see it like this: I wouldn’t touch C or C++ without a 10-ft pole. Rust is my 10-ft pole.

        That being said, I think python occupies a very different space from rust and allows for super rapid prototyping so I wouldn’t conflate the two

      • @verstra@programming.dev
        link
        fedilink
        28 months ago

        It feels like the last language one will need to learn.

        It has an improved C-style syntax (if statement is similar to if expression), it has algebraic type system (enums can contain nested data) and 99.9% of the time you can write in safe mode where you are guaranteed not to segfault.

      • Macil
        link
        fedilink
        English
        1
        edit-2
        8 months ago

        Rust is the only language with the same low-level memory model of C/C++ (no garbage collector, focus on zero cost abstractions, etc) while also being memory-safe (like nearly all popular modern languages besides C/C++). Before Rust, you often had to choose between memory safety and performance.

  • @signor@lemmy.world
    link
    fedilink
    78 months ago

    So how fucked am I for starting to learn cpp as my first language, or is this a later down the road thing to worry about?

    • @thomask@lemmy.sdf.org
      link
      fedilink
      English
      98 months ago

      If you can write correct C++ you’ll be able to write Rust code that compiles first time. Don’t stress, you’re learning the good stuff.

    • @lysdexic@programming.dev
      link
      fedilink
      English
      88 months ago

      So how fucked am I for starting to learn cpp as my first language, or is this a later down the road thing to worry about?

      I don’t see why you should be concerned, except that no professional software developer is limited to use one specific programming language.

      Even if you pay attention to the disaster prophets in the crowd, which are mainly comprised of fanboys implicitly and explicitly promoting their pet language/frameworks, C++ dominates all aspects of the computing ecosystem, which means that in the very least the whole world needs to maintain existing C++ projects to continue to work. See COBOL for reference.

    • Oliver Lowe
      link
      fedilink
      58 months ago

      Ah that’s an easy one - what would you like to do?

      My first uh… “language” was bourne shell. Not because I thought it was a cool language, but because that’s what let me do things I wanted to do at the time: automate heaps of Linux, BSD stuff.

      There are heaps of libraries and applications where C++ is the choice e.g. video games. My friend is great at Javascript because he loves web browser tech.

      Don’t stress - have fun! :)

    • There will be plenty of jobs in c++ in the foreseeable future, so it’s not a bad language to know from that perspective. I don’t know if it’s the most pedagogical language to learn otoh, python is a better language for getting comfortable with the basics, c is better when it comes to learning a (slightly wrong but close enough) mental model of how a computer works under the hood, and there are many better languages to learn if you want to learn good approaches to thinking about problems.

      Maybe you are leaning c++ because you want to work on something specific that c++ is primarily used in, and in that case go ahead with that project. I think having something tangible that you want to work on is great when it comes to learning programing and that’s worth more than picking the “best” language. Besides, you can always learn different languages later in your career if you want/have to.

    • cum
      link
      fedilink
      English
      2
      edit-2
      8 months ago

      It’s a great language to learn. The memory safety specifically. If you only use memory safe languages, you won’t know anything about how the memory is handled in the background. Start breaking and abusing memory, it’s the best way to learn why memory safety is important, what it’s doing different, and how it’s prevented.

      Getting deep in the trenches with memory allocation is the best way to learn, since all memory safe languages do this as well, they just hide it. It’s extremely useful to know what’s going on behind the scenes and is fundamental knowledge that applies to all programming languages, past and present, no matter how much they hide it.

  • @words_number@programming.dev
    link
    fedilink
    58 months ago

    Kinda sad how that guy destroys his reputation so late in his life. I mean he actually contributed a lot to the field of software development, but just refuses to accept that C++ days are thankfully over. The language has grown into a complete abomination, but all the experience we gained during its long history (good and bad) are extremely valuable for designing new languages from now on. One can’t rescue a design by just adding things to it (regardless of the kind of design), that’s just a simple truth. Thus, a backwards compatible C++ can never become even half as good as rust is already today (and there’s of course always room for improvement). But that’s not because bjarne did something stupid, but because humanity as a whole didn’t know better back than. He could just accept that, embrace new technology, retire in dignity, be remembered as highly admired and appreciated. Instead he acts like a butthurt idiot, trying to defend that cars shouldn’t have seatbelts, because if everyone drives carefully, nothing bad will happen anyway. Pathetic.

    • mox
      link
      fedilink
      218 months ago

      One can’t rescue a design by just adding things to it (regardless of the kind of design), that’s just a simple truth.

      This statement could also be applied to Perl, PHP, JavaScript, and most other languages that eventually add new ways of doing things, especially if they preserve backward compatibility. I’m not sure that this is a condemnation of C++ so much as an inevitable consequence of being successful for a long time.

      To be clear, I’m not defending C++. Just pointing out that it’s not unusual in this regard. I have no doubt that Rust will also have vestigial warts in time, if it doesn’t already.

      • Superb
        link
        fedilink
        English
        88 months ago

        Why can’t it be both a condemnation of C++ AND an inevitable consequence of success? C++ was a success, but we’ve learned a lot and it’s time to move on

        • mox
          link
          fedilink
          88 months ago

          Condemning apples for having seeds doesn’t make a reasonable case for choosing other fruit, which also have seeds.

          • snoweM
            link
            fedilink
            08 months ago

            it does if the other ones have edible seeds, seeds without arsenic, or fewer seeds… your analogy makes no sense.

      • @Corbin@programming.dev
        link
        fedilink
        English
        78 months ago

        You are very close to a deep truth of language design: all large popular languages slowly die from committees overloading them with cruft and redundant features, and at the end of their healthspans, they become painful for all involved. In your list, this includes both PHP and ECMAScript; Perl 5 avoided this fate, but Raku certainly suffers from it.

    • @Cirk2@programming.dev
      link
      fedilink
      5
      edit-2
      8 months ago

      Bringing more modern tools and features to existing large code bases is “destroying his reputation”? Bjarne and the committee is constantly extending and modernizing a language with code bases older than me. Yes that means the old stuff has to be kept around but that is the price of allowing existing code to migrate gracefully instead of just throwing it out of the window. There is a problem with some missing rails to enforce current and saver techniques but Bjarne is not denying that.

      • @words_number@programming.dev
        link
        fedilink
        58 months ago

        Bringing more modern tools and features into C++ is good. Acting as if that would make it equally suitable for new projects or even equally safe as languages that don’t (yet) suffer from carrying around a ton of legacy garbage nobody should use (both in terms of features and std items) is ridiculous though.

  • cum
    link
    fedilink
    English
    38 months ago

    Oh boy, the Biden admistration is in their nerdy programming language phase. I’m scared for when the administration gets into WM vs DE and warns about the bloat of not using suckless software.