Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Google

To Help Rust/C++ Interoperability, Google Gives Rust Foundation $1M (siliconangle.com) 61

Posted by EditorDavid from the Rust-never-sleeps dept.
An anonymous Slashdot reader shared this report from SiliconANGLE: The Rust Foundation, which supports the development of the popular open-source Rust programming language... shared that Google LLC had made a $1 million contribution specifically earmarked for a C++/Rust interoperability effort known as the "Interop Initiative." The initiative aims to foster seamless integration between Rust and the widely used C++ programming language, addressing one of the significant barriers to Rust's adoption in legacy systems entrenched in C++ code.

Rust has the ability to prevent common memory errors that plague C++ programs and offers a path toward more secure and reliable software systems. However, transitioning from C++ to Rust presents notable challenges, particularly for organizations with extensive C++ codebases. The Interop Initiative seeks to mitigate these challenges by facilitating smoother transitions and enabling organizations to leverage Rust's advantages without completely overhauling their existing systems.

As part of the initiative, the Rust Foundation will collaborate closely with the Rust Project Leadership Council, stakeholders and member organizations to develop a comprehensive scope of work. The collaborative effort will focus on enhancing build system integration, exploring artificial intelligence-assisted code conversion techniques and expanding upon existing interoperability frameworks. By addressing these strategic areas, the initiative aims to accelerate the adoption of Rust across the software industry and hence contribute to advancing memory safety and reducing the prevalence of software vulnerabilities.
A post on Google's security blog says they're excited to collaborate "to ensure that any additions made are suitable and address the challenges of Rust adoption that projects using C++ face. Improving memory safety across the software industry is one of the key technology challenges of our time, and we invite others across the community and industry to join us in working together to secure the open source ecosystem for everyone."

The blog post also includes this quote from Google's VP of engineering, Android security and privacy. "Based on historical vulnerability density statistics, Rust has proactively prevented hundreds of vulnerabilities from impacting the Android ecosystem. This investment aims to expand the adoption of Rust across various components of the platform."

The Register adds: Lars Bergstrom, director of Android platform tools and libraries and chair of the Rust Foundation Board, announced the grant and said that the funding will "improve the ability of Rust code to interoperate with existing legacy C++ codebases.... Integrating Rust today is possible where there is a fallback C API, but for high-performance and high-fidelity interoperability, improving the ability to work directly with C++ code is the single biggest initiative that will further the ability to adopt Rust...."

According to Bergstrom, Google's most significant increase in the use of Rust has occurred in Android, where interoperability started receiving attention in 2021, although Rust is also being deployed elsewhere.... Bergstrom said that as of mid-2023, Google had more than 1,000 developers who had committed Rust code, adding that the ad giant recently released the training material it uses. "We also have a team working on building out interoperability," he added. "We hope that this team's work on addressing challenges specific to Google's codebases will complement the industry-wide investments from this new grant we've provided to the Rust Foundation."

Google's grant matches a $1 million grant last November from Microsoft, which also committed $10 million in internal investment to make Rust a "first-class language in our engineering systems." The Google-bucks are expected to fund further interoperability efforts, along the lines of KDAB's bidirectional Rust and C++ bindings with Qt.
This discussion has been archived. No new comments can be posted.

To Help Rust/C++ Interoperability, Google Gives Rust Foundation $1M More

To Help Rust/C++ Interoperability, Google Gives Rust Foundation $1M

Comments Filter:
  • Old codebases need maintenance. It is a technical debt that comes due eventually. The most direct approach to improve security and quality of C++ project is to migrate to more recent C++ specification and compilers. Adding layer of "rust" to old codebases is not going to make them safer or better.

    • That seems to be Google's goal here. The goal of carbon is to "upgrade" existing code. If you're familiar with rust, have a look at carbon. The syntax is strikingly similar. But to rewrite a borrow checker as robust as rust's is a MAJOR undertaking, and you don't even get to benefit from other modern features of rust like async. So I think it would make sense to just nix that idea entirely and have rust do what they originally intended with carbon.

      Upgrading the C++ specification of old code still won't do a

      • Those temporal memory problems btw are solved in a c library pretty often. C++ allows do data types to be created with little thought to how to stop leaks, buffer over runs, under runs.... Rust is no different I believe

        • The idea that the solution to c++ memory problems is to use C is hilarious to me.

          • Re: (Score:3)

            by gweihir ( 88907 )

            That is because you do not understand the problem. The problem is hidden effects in C++, both due to the really bad language design and due to complexity that is not needed but stems from bad software design and architecture. In C, you can at least see things clearly.

            • Re: Pay down technical debt, not incur new one (Score:4, Insightful)

              by LindleyF ( 9395567 ) on Saturday February 10, 2024 @07:52PM (#64231102)
              It's possible to do things stupidly in any language. Let's assume we don't do that. C++ allows you to define operations and abstractions that are safe by construction. You can get this wrong, but if you get it right, analysis is much simplified. C, by contrast, does not want you to use much abstraction. You see exactly what's going on, but you have to remember to explicitly handle many more details. It comes down to the power of abstraction. When used well, it is an incredible ally.

            • That is because you do not understand the problem.

              No, GP doesn't. And apparently neither do you.

              The problem is hidden effects in C++, both due to the really bad language design and due to complexity that is not needed but stems from bad software design and architecture. In C, you can at least see things clearly.

              C very much has the same problem. The only way C++ is notably different here is implicit destruction, whereas C the lifetime is explicit. We still see the same problems in C that we do C++. All the time in fact. Admittedly though, C++ with its OOP crap makes it a hell of a lot easier to create subtle but very dangerous bugs.

              NB: Decades of C++ and Java are THE reason developers are so skeptical of languages like Rust, so I'm not bothered by mere skepticism from t

              • Bleh, editing mistake. Both languages == C++ and Java.

              • You mentioned destructors in passing, but they're enormously important. Te ability to tie resource lifetime to a scope is one of C++'s biggest advantages over C, IMO. Especially once you layer semantics on top of it by your choice of smart pointer (if any).

              • Re: (Score:2)

                by vyvepe ( 809573 )

                I think C will always have a place in custom silicon architectures because the language is relatively simple to implement (though I'm just taking compiler writers' words for that.)

                Zig wants to take that space.

            • Re: (Score:2)

              by SirSlud ( 67381 )

              My feeling today after having both learned some rust and working with people who know rust really well now - in an environment and industry in which we're all c/c++ heavy hitters and have plenty of reasons, both technical and inertia/career/ecosystem based to favor them - is that rust is coming for lunches. Comments like yours, I suspect it doesn't really matter for you in any economic sense, so it's easy for you to act like you know. Just know that you're wrong.

              • Re: (Score:2)

                by gweihir ( 88907 )

                I don't think so. And I have seen promises and predictions like these before, in fact on several different "waves" of programming language designs. They never pan out. Sure, Rust may (or may not) kill C++, which is a language so horrible it does not take that much to do it. But C? Forget about it. C has a ton of advantages in the hands of somebody that knows what they are doing. Rust cannot compete.

            • In C, you can at least see things clearly.
              And why would you not see things clearly in C++ ?

            • C is even more capable of hiding memory issues than C++ because of all the stupid cut and paste, macro abuse, and language abuse you have to use to try to emulate functionality that the C++ compiler provides.

        • Those temporal memory problems btw are solved in a c library pretty often.

          I'm not sure what you're referring to but neither C nor C++ can properly manage pointer lifetimes. They both leave this entirely up to the programmer. There are libraries like garbage collection for both, or for C++ only, destructors that zeroize data, which only serves to mitigate leaks but still doesn't address undefined behavior.

          ALL of these solutions come at a performance cost.

          C++ allows do data types to be created with little thought to how to stop leaks,

          In C++, that is a VERY dangerous assumption to make. Especially when doing concurrency.

          buffer over runs,

          That is not temporal safety, you're think

          • If you try hard enough you can achieve those states without even using pointers. Memory errors can almost always be attributed to incorrect bounds checking. I just think the reason things like drivers in an OS like linux for example, are not in c++ is that mentioned bounds checking environment. I also suspect rust has the same problem.

            • If you try hard enough you can achieve those states without even using pointers. Memory errors can almost always be attributed to incorrect bounds checking.

              No...You have to be pretty careless to get bounds checks wrong. That's the most easily preventable kind of memory error. I don't know what languages you use, but picture it this way: Say you declare an array of the numbers 0 1 and 2. You then write a a loop to read from each, but you tell it to stop at index three because you have a three byte array. Problem is, index three is out of bounds, so whatever data you read from that last index is invalid. This is also considered a pointer arithmetic error even th

          • ALL of these solutions come at a performance cost.

            Just like Rust. They still haven't figured out how to specialize generics. TANSTAAFL. You gotta pick what you want.

          • You do not know much about C++

            So basically everything in your post above is wrong.

            • You know who you remind me of? If you've ever played punch out, the second easiest guy in the game is Von Kaiser, who calls himself a boxing teacher, but he's so bad at it. In the wii version of the game his own students were beating him.

              And what a coincidence, you're both German. Makes me wonder if they were inspired by you when they made him.

              • And you remind me about a guy from China. Who had a PhD in chemistry and thought he could program.
                So he was hired.
                Wrote like 50k lines of code.
                40k commented out.
                10k doing the job in an incomprehensible way.
                With 2 bugs he could not fix himself.

                So we reimplemented the whole thing in a week in Java.

                Has nothing to do with Java versus C,

                But you are an idiot, and you do not know it. As soon as you realize you are an idiot: you can start growing.

                • Except I've done nothing to demonstrate that. You have.

                  • You demonstrate in every post, that you are either ignorant, an idiot, or both.
                    Your pick.

                    • Then why is it that you can never prove it? I've always proven it in your case.

                    • Well, same for you, or not?
                      Making claims about C++ without and proof.
                      So? Or your idiotic claims about C# versus Java (and their VMs).
                      Or your inability to grasp linked lists.

                    • Well, same for you, or not?

                      Definitely not.

                      Making claims about C++ without and proof.

                      Which one, exactly? Be specific.

                      So? Or your idiotic claims about C# versus Java (and their VMs).

                      This shit is easy to prove schweinehund. Like I told you before, Java has no equivalent to this:

                      https://learn.microsoft.com/en... [microsoft.com]

                      That's because JVM offers zero in the way of runtime control over the GC. Exactly like I keep telling you, and you keep insisting is false anyways despite me proving this multiple times already.

                      Or your inability to grasp linked lists.

                      Schweinehund... Your own godfather even agrees with exactly what I've been saying about linked lists:

                      https://youtube.com/watch?v=YQ... [youtube.com]

                      What mor

                    • Java has the same control over all aspects of GC like the CLR VM.
                      You are simple ignorant.
                      Your previous posts about C++ were all wrong.

                      No idea who you think my 'godfather' is. As far as I'm aware, my father was a mere mortal.

                      A deque is a data structure.
                      A linked list is an implementation of such a data structure.
                      A deque is not supposed to be (efficient) inserable in the middle.

                      The standard (and most efficient in amortized time) is a double linked list. Inserting and removing from both ends is constant. If you

          • You do not know much about C++
            I mentioned that already.

            Basically everything you say regarding C++ in your various posts: is wrong

            You should learn the language, or admit: you never used it (properly). So, you have no clue about it.

            destructors zeroing out memory just lolz. IFF you are in DEBUG mode and want special behaviour for destructors, THEN 0xdeaddeaddeaddead into the memory. Because on basically every architecture, that is an invalid address, and you see in memory at the first glance without any debugg

    • Re: (Score:1)

      by dfghjk ( 711126 )

      "The most direct approach to improve security and quality of C++ project is to migrate to more recent C++ specification and compilers."

      Whatever that means. It's certainly the easiest thing to do, particularly when "security and quality" themselves don't have concrete meaning.

      "Adding layer of "rust" to old codebases is not going to make them safer or better."

      For some undefined meaning of safer and better yeah that's probably right, just like migrating to more recent C++ specifications and compilers won't.

    • The most direct approach to improve security and quality of C++ project is to migrate to more recent C++ specification and compilers.

      How recent? Is this enough?

      g++ --version
      g++ 12.2.0
      Copyright (C) 2022 Free Software Foundation, Inc.

      Is there anything wrong with this code?

      #include <vector>

      int main() {
      auto v = std::vector<int>({1, 1, 1, 1, 1, 1});
      for (auto n : v) {
      if (n == 1) {
      v.push_back(2);
      }
      }
      return 0;
      }

      The compiler seems to think it's OK:

      $ g++ -Wall -pedantic

      • - Doctor, doctor, it hurts when I do this!
        - Don't do it, then.

      • I would have expect that a static analysis would detect if you modify the size of a vector while iterating it. But clang scan-build didn't seem to care either.

        • Re: (Score:2)

          by gweihir ( 88907 )

          Static analysis is actually very limited in what it can do. It can only find simple things because otherwise it runs in prohibitively bad memory issued and even worse execution time problems.

          The only solution still is and may remain forever unless AGI is actually possible - something that seems less and less likely - coders that _really_ understand what they are doing. These people are very rare, expensive and do not take crap from "management". Hence most places try to do without them, with predictable res

      • This is because C++ collections are implemented as a library. Enabling libstdc++ debug mode will catch most of undefined behavior. See libstdc++ debug mode [gnu.org]

        • If I have to run in C++ slow debug mode, maybe I should just use a safer, slightly slower language like Java, Go or Pascal in the first place.

          "But you only use debug mode while your developing!"

          That's probably only testing the happy paths.

          "Then you should use $CODE_COVERAGE_TOOL!"

          This is really getting complicated and expensive. Why not just begin migrating to Rust like the article said?

    • Re: (Score:2, Interesting)

      by gweihir ( 88907 )

      Indeed. But the "new is better and Rust is best!" fanatics are incapable of seeing that. Going to two languages were there was one will always increase complexity and that will negate all benefits of the move and routinely make matters much worse. The only way a hybrid design will ever be beneficial is if it was hybrid right from the start and carefully planned to be that way. Takes some real experience to see that though. The Rust-fanatics are generally lacking that.

      From the degree reality is denied here,

      • Re: (Score:2)

        by SirSlud ( 67381 )

        On what planet was "there was always one?" Oh right, on none planet.

      • This comes down to the language interop mechanism being C.

        IF, and that's a big IF, this manages to create a way to call rust from C++ and C++ from rust in a way that keeps (most of) the benefits of both languages, it will all become more interesting.

        • Re: (Score:2)

          by gweihir ( 88907 )

          This comes down to the language interop mechanism being C.

          IF, and that's a big IF, this manages to create a way to call rust from C++ and C++ from rust in a way that keeps (most of) the benefits of both languages, it will all become more interesting.

          If they manage that, it will be a feat never achieved before and though practically impossible by many for good reasons. Hence I doubt they will manage it. Given the usual mode of the Rust people, they may well lie about it though.

        • That is not a big IFF:
          read https://docs.rust-embedded.org... [rust-embedded.org] and the follow up chapter.

    • Adding layer of "rust" to old codebases is not going to make them safer or better.

      Bbbbut.... I was told that just adding Rust would fix all of my memory bugs! Was I lied to? /s

      By the same argument, adding "rusty" C++ support to Rust isn't going to help Rust in anyway, nor make the code safer. If anything, I'd imagine that some of that desired C++ support may very well require the use of the unsafe Rust keyword [rust-lang.org] to implement properly. Which would only harm Rust's reputation because the whole point of Rust is that the end-programmer doesn't have to explicitly check for "soundness" themse

Slashdot Top Deals

Every nonzero finite dimensional inner product space has an orthonormal basis. It makes sense, when you don't think about it.

Close