Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Programming

Rust Programming Language: We Want To Take It Into the Mainstream, Says Facebook (zdnet.com) 74

Facebook has joined the Rust Foundation, the organization driving the Rust programming language, alongside Amazon Web Services, Google, Huawei, Microsoft, and Mozilla. From a report: Facebook is the latest tech giant to ramp up its adoption of Rust, a language initially developed by Mozilla that's become popular for systems programming because of its memory safety guarantees compared to fast languages C and C++. Rust is appealing for writing components like drivers and compilers.

The Rust Foundation was established in February with initial backing from Amazon Web Services, Google, Huawei, Microsoft, and Mozilla. Microsoft is exploring Rust for some components of Windows and Azure while Google is using Rust to build new parts of the Android operating system and supporting an effort to bring Rust to the Linux kernel. Facebook's engineering team has now detailed its use of Rust beginning in 2016, a year after Rust reached its 1.0 milestone. "For developers, Rust offers the performance of older languages like C++ with a heavier focus on code safety. Today, there are hundreds of developers at Facebook writing millions of lines of Rust code," Facebook's software engineering team said.

This discussion has been archived. No new comments can be posted.

Rust Programming Language: We Want To Take It Into the Mainstream, Says Facebook

Comments Filter:
  • Rusty savings. (Score:4, Informative)

    by Ostracus ( 1354233 ) on Thursday April 29, 2021 @03:30PM (#61329238) Journal

    For developers, Rust offers the performance of older languages like C++ with a heavier focus on code safety.

    There's an economic aspect as well. Just how much has unsafe code cost economies across the world?

    • Probably less than all the maintenance and bugs related to "time zones"
    • by short ( 66530 )
      It cannot reach performance of C++ as Rust does not have move constructors. Even the trivial `std::string` type needs move constructor to be effective (to have local storage for short strings).
      • There are legitimate criticisms of Rust. Performance isn't one of them.

        • Compared to C++, it actually is. A lot of unfortunately necessary template metaprogramming goes into stuff like expression templates to implement domain specific expression analysis/optimization and lazy-ish evaluation. Rust's lack of Turing complete templates means it simply can't go that route.

          Rust's Arc, making it safe to share data in multithreaded environments, misses the point, because synchronization kills performance. Making it easier to synchronize just makes it easier to use subpar designs. Cho
          • I would be fascinated to see your links to benchmark results.

              • Appears to be no benchmark content whatsoever in your link. Sorry, got to regard your comments as unsubstantiated. More in the realm of speculation.

                • The lack of benchmarks comes from the Rust side. Plenty of benchmarks for Eigen, and it compares well with Intel's highly tuned math library (which uses some Fortran, which is supposedly faster than C++), and outperforms it in many cases. If Rust can reach that performance, surely they'd be promoting the hell out of those benchmarks.

                  https://eigen.tuxfamily.org/in... [tuxfamily.org]

                  Just a brief search on the issue shows Rust crates just wrapping Intel's MKL, which says to me my point about C++ template metaprogramming
                  • I believe you were trying to come up with a legitimate performance criticism of Rust and so far haven't. I'd be interested in anything substantive you came up with, but that last attempt was, I'm sorry, very weak.

                    I'm not seeing Rust as substantively different from C or C++ in what its optimization limits are. You mentioned more limited generics. But Rust has Turing-complete procedural macros that can generate code, so I'm not seeing that as advantage C++. I think Rust may have the same memory aliasing advan

                    • I literally linked to benchmarks comparing Eigen to libraries that also use Fortran for some parts, and it outperforms them handily in quite a few of them. Your whole comment is unsubstantiated handwaving compared to the CONCRETE BENCHMARKS I linked to.

                      but that last attempt was, I'm sorry, very weak.

                      I'm sorry you moved the goalpost from "no benchmarks" to "sorry, but I'm ignoring your benchmarks in favour of debunked Fortran handwaving." Your latest effort is very very weak. You have no benchmarks. I have. By your own criteria before you shifted goalpost

                    • Furthermore:

                      You mentioned more limited generics. But Rust has Turing-complete procedural macros that can generate code, so I'm not seeing that as advantage C++.

                      Funny how you allow this bit of handwaving, and yet, my earlier "handwaving" link to a discussion has this to say:

                      Comparing the current idiomatic libraries Rust libraries (ndarray, nalgebra, ...) against Eigen is not really useful nor fair because Rust does not allow them to do what's necessary to become more like Eigen. One would need to write a compiler-plugin that can access type information for this.

                      My handwaving beats your handwaving.

                  • That there are Rust bindings to a native library tells you that this is because Rust lacks generics and metaprogramming? That seems a pretty big jump. I would say that someone has produced Rust bindings because there is already a library there and that's quicker than rewriting in Rust from scratch.

                  • Comment removed based on user account deletion
          • Rust's Arc is there for a specific purpose -- to provide synchronized access to a reference counted object. It's not the only mechanism for multithreaded environments and Rust has several other mechanisms, including channels and async. Are you criticising Rust for having a mechanism like Arc's because it's too simple? No language should be so doctrinaire about concurrency; there is no single solution that fits all requirements.

            • No, I'm criticizing Rust evangelists for harping on about Arcs as though they're the solution to multithreading. Arcs consistently get mentioned above channels and async, because truth be told, channels and asyncs are the better abstraction most of the time, and every language has them or libraries for them already.
      • Re:Rusty savings. (Score:5, Informative)

        by slack_justyb ( 862874 ) on Thursday April 29, 2021 @05:56PM (#61329768)

        as Rust does not have move constructors

        By default Rust copies nothing and moves all. So Rust doesn't need move semantics since by default that's all it ever does. You actually have to opt-in for copies which is the copy trait [rust-lang.org] because copying is much more dangerous than moving. Rust uses an affine type system [wikipedia.org] meaning that you either use them once or never, but never anything outside of those two options unless you explicitly opt-in for copies or clones. If you've ever used Haskell, it's literally the same thing they do there.

        So you can think of it like, you define String in foo and foo will call bar. So you have the following options. (1) You can move String into bar, foo can never access it again. That is the String is now within the call stack of bar, so when bar is done, String is deallocated (this is the default). (2) You can borrow String into bar, foo has full access to it, bar has only a read-only reference. String is in foo's call stack and bar may not mutate. (3) You can mutable borrow String into bar, String is still part of foo's call stack, but now it is unsafe for foo to do anything with String meaning if you really want to access String after the call to bar, you must wrap it in unsafe{}

        C++ has move semantics because back in the day by default it attempts to copy things, even for temp objects. It wasn't until rvalues were added to the compiler that C++ had this notion of "Oh snap! It's better to move than to copy, let me just see if there's a move c-tor." In Rust you have Clone (which can be deep or shallow, you get to define it) and you have Copy which is always memcpy. Clone is always explicit, there will never be an implicit clone [rust-lang.org] as it's pretty universally hated on by the Rust team. If you mark something with Copy then you've opted-in for Copy and thus you'll get implicit copy, which is implemented as memcpy, unless you specify & or mut&.

        So yeah, you have to give some thought on what you will need your objects for before you just tag it Copy. Leaving the default affine system isn't something done lightly in Rust. This is actually one of those things people indicate about the learning curve of the language, you just can't willy nilly tag your structs whatever. These opt-ins are a one way thing, once you're in, someone later on in the code base can't just opt-out. Which means once you opt-in, everyone has to obey the interface that comes with the trait you tagged in on your struct, otherwise the compiler will complain.

        • It wasn't until rvalues were added to the compiler that C++ had this notion of "Oh snap! It's better to move than to copy

          Not strictly true. Copy-elision was a very early technique for optimization. Walter Bright, who invented D, was the person who invented return value copy elision for C++ back in the early 90s. So in actual fact, in C++, it was better to not move than move.

          Before rvalue references, there was swap, which is technically just a move if implemented by the specific type. It was just that it was confusing to some because of ADL. But as long as you implemented swap, then all the standard containers, and other co

        • by short ( 66530 )
          > Rust doesn't need move semantics

          This is the performance problem of Rust: std::string internal representation [jankratochvil.net]

          You have to change _M_p during a move or copy but you cannot in Rust. So you cannot have effective implementation of various types which would need internal references. Rust implements them without internal references but that is 10x slower in the current world of internal-to-external bus speed 1:10.

          Why can't I store a value and a reference to that value in the same struct? [stackoverflow.com]

          • You can have internal references in Rust. These are implemented with raw pointers which move outside of safe Rust, but which can be used to implement self-referential types.

        • by Tom ( 822 )

          This is actually one of those things people indicate about the learning curve of the language, you just can't willy nilly tag your structs whatever.

          Correct. Getting the borrow system is the thing I found (and still find, sometimes) to be the most difficult to wrap my head around. Not in understanding it when written down, but in using it. I still sometimes forget that I can't change this variable because it's just borrowed, etc.

          But that was a good explanation there. Thinking about ownership in terms of "on whose stack is this stored?" helps.

        • by TopherC ( 412335 )

          I want to nit-pick about this bit:

          ... String is still part of foo's call stack, but now it is unsafe for foo to do anything with String meaning if you really want to access String after the call to bar, you must wrap it in unsafe{}

          After the call to bar, foo can still access the string -- no unsafe{} needed. foo gave bar a mutable borrow, so the assumption is that the string may have changed. Maybe you're referring to rules about only one mutable borrow in use [github.io]?

      • by Bengie ( 1121981 )
        Rust makes heavy use of provable compile-time optimizations. It can optimize away moves. Speaking of moves, it can even optimize away reallocations. In some cases it will treat allocations like the stack. It will see that the life-time of some data is such that it can do a single larger allocation instead of a bunch of smaller ones, then place the upcoming "allocations" on this stack of memory.

        You focus on writing clean code and let the compiler deal with making it fast, like it should be.
    • by Bengie ( 1121981 )
      Seeing that over 50% of security bugs are a class of bug that is impossible in safe Rust code and in many cases even "unsafe" Rust code, I would venture to say Rust will be useful in kernels and parsing. I've read blogs from C and kernel programmers that Rust can actually be much faster than C because C is difficult to safely use with certain datastructure and algorithms. Essentially a good programmer is forced to use sub-optimal datastructure and algorithms in C because clean-code > fast code when it co
    • how about "i wanna choose how i do it" ?
  • by Anonymous Coward on Thursday April 29, 2021 @03:44PM (#61329288)

    The blocker for Rust to take over C is the lack of compilers and platform support. It only runs on a small subset of platforms, not even everywhere LLVM runs. It has the major platforms, but C runs everywhere.

    Need a GCC rust or some other source that doesn't depend on LLVM. LLVM devs block wide platform support with their fee based model of buying hardware/vms for them to test on. It's cost prohibitive for small projects.

    • by Anonymous Coward

      Rust doesn't have to "take over C", it just has to be used where it's needed. The bast bulk of exploits are against network clients like browsers, network services, and file processors like media viewers or archivers. On a discrete set of platforms: AMD64 and ARM.

      Boiling the ocean will never win, but targetted RUST can.

    • Which is why someone is working on a GCC front end for Rust. And also why Rust is working on increasing the number of their "tier" platforms and the formalisation of what their tiers mean.

      Having said this, Rust does run on a fair few platforms including most of the ones that run the cloud. If you are targetting those platforms, that Rust doesn't run on other platforms is probably less of an issue.

    • by jeremyp ( 130771 )

      I don't understand your last point. LLVM is open source. Anybody can write a back end for any target. Well, I say "anybody": I took a look at it once and the learning curve is steep.

  • by BAReFO0t ( 6240524 ) on Thursday April 29, 2021 @03:55PM (#61329342)

    ...to ease a certain type of C coders who refuse to use anything else yet claim to know that C is the best language ever, into some of the amenities computer science has come up since then.

    If you're not one of them, nor write any low-level code, like actually *implementing* those amenities (and garbage collectors), it's still a bad choice, like C.
    I'd consider anything Facebook does not low-level.

    So for the Linux kernel: Yay.
    For Facebook: Are you kidding me?

    That's my take.

    (I started out with 8086 and 6402 assembly, Pascal and C, in case you questioned my right to judge this.)

    • > 6402 assembly

      I'm assuming that was an off-by-one key typo? ;-)

      i.e. 6502 assembly

    • by GuB-42 ( 2483988 )

      I don't know much about Facebook, and I suspect a lot of it is confidential, but for companies of that size, optimizing software down to the lowest level can save them millions.
      By low level, I mean that I wouldn't find is shocking if they had ASICs designed just for them. As for the Linux kernel, of course they contribute, and they actually have a pretty good track record.

    • Facebook Smartphone Aps are not great candidates for Rust. Internal Facebook infrastructure may have use for it. For example, it is rumored that Facebook uses their own customized servers.
    • They're likely using Rust for backend data operations, not anything user facing. With the amount of ad and user data they collect and process it would make sense.
    • by Tough Love ( 215404 ) on Thursday April 29, 2021 @06:56PM (#61329890)

      Rust is for those who want modern programming tools without a garbage collector but with memory safety, and who have an extremely high pain threshold.

    • by piojo ( 995934 )

      [Rust only exists] to ease a certain type of C coders who refuse to use anything else yet claim to know that C is the best language ever, into some of the amenities computer science has come up since then.

      Some years ago I wrote a shell script to gather analytics about files on a full hard drive. It ran out of memory, which was no surprise due to the bytes of the filenames alone. I came up with some clever optimizations, but rewrote it in perl. Bash/zsh were too limited to easily enable clever programming and the debugging that goes with it. Ruby and Python were out because of performance needs. Plus I wanted a language with some static parsing, checking, and warnings. C++ was out because I find that's best a

  • I'm following some of the discussion on the kernel mailing list and it's very eye opening in the way of showing a bit of the development process being commented on by real folks. So far... As I suspected the proposed language can be simply passed to a wrapper scheme that will handle the memory calls, locks, file writes, etc,.... Which technically means you can use ANY language to say, write drivers for the kernel? If the necessary libraries are included in the kernel?
  • I said it before and I will say it again. It's getting harder to avoid rust than SystemD. If instead efforts were made to improve C's memory safety instead of making a whole parallel set of libraries and compilers we would have less bloat in computers.
    • > If instead efforts were made to improve C's memory safety instead of making a whole parallel set of libraries and compilers

      You could do that but unfortunately by the time you are done you have effectively created yet-another-language bastard stepchild which is no longer compatible with C. Who is going to learn this language?

      At some point you have to give up C's undefined nature and nail things down. This right there is incompatible.

      Part of the advantage and disadvantage of C is that arrays and pointe

      • Re: (Score:3, Interesting)

        Rust can be made to run on everything if they simply change the compiler back-end, so I don't see that as a disadvantage.

        There are so many problems introduced by C, not the least of which is that it makes our entire infrastructure totally insecure from hackers, that we absolutely need to replace it.

        I myself have stated that the biggest problem is that we are using systems programming languages (C, C++) where we should be using application programming languages. The problem is the only application prog
        • by TopherC ( 412335 )

          Using iterators vs bounds checking: Rust makes using iterators easy, but also provides bounds checking for array element access. Often that's an O(N) versus O(1) issue. One place Rust feels inconvenient is indexing strings. To be safe, you must use iterators for that because of UTF-8 and stuff.

          And you can opt-out of bounds checking in Rust if you're inside unsafe{...}. But the idea is to use "unsafe" as little as possible, and to isolate it in packages that have thorough unit testing. No language can preven

      • by Uecker ( 1842596 )

        Rust was partially inspired by safe variants of C, e.g. cyclone. So I think it could be done. One would start from the other end, introducing a safe subset which is continuously expanded.

        Safe string and container libraries for C exist. The problem is that they are not part of the standard library, so many programmers try to code their string handling and data structures and fail to do this correctly.

        In C, pointers and arrays are *no*t the same thing. And with arrays you can get light-weight run-time bounds

        • > in C, pointers and arrays are *not* the same thing

          I never said they were. I said arrays and pointers are synonymous.

          You are confusing semantically, functionally, equivalence, and equal. --> Equivalent does NOT mean equal.

          Functionally BOTH may be equivalent. From C99 [open-std.org] 6.3.2.1/3 (emphasis added):

          3 Except when it is the operand of the sizeof operator or the unary & operator, or is a string literal used to initialize an array, an expression that has type "array of type" is converted to an expression with type "pointer to type" that points to the initial element of the array object and is not an lvalue.

          That is, arrayname by itself is equivalent to &arrayname[0], as the following program demonstrates,

          #include <stdio.h>
          void main()
          {
          int a[] = { 1, 2, 3 };
          int *p = a; // C99

          • by Uecker ( 1842596 )

            I think it is you who are confused about the meaning of the word "synonymous". But anyway, arrays and pointer are also not equivalent. As you correctly observe an array lvalue is converted to a pointer to its first element during lvalue conversion. But otherwise arrays and pointers are still different types and array types have a length as compile-time and run-time meta data. You can pass around pointers to arrays just fine while preserving this bound. In other words, C has a bounded pointer type and one c

    • by TopherC ( 412335 )

      How do you propose doing this? Annex K? [open-std.org] Even if that were all it was intended to be, it would not begin to scratch the surface of what Rust accomplishes in safety. Rust's approach is so fundamentally different than C, I don't see how one could mold either language to be even a little bit like the other.

      I love programming in Rust! Well, except when I'm shouting obscenities at the compiler. Not sure which is more common. But it has successfully prevented me from doing more than a few stupid things that I was

      • by Uecker ( 1842596 )

        The idea would be to introduce a safe subset of and additional annotations that express certain constraints. A compiler could then make sure that there is no UB in your code at compile-time. There exist safe variants of C (e.g. cyclone) and Rust was partially inspired by them.

    • If they did that it wouldn't be C anymore.

  • by beep54 ( 1844432 ) <b54oramaster@[ ]il.com ['gma' in gap]> on Thursday April 29, 2021 @05:12PM (#61329588)
    I thought Rust WAS mainstream...
    • for what? Language has some great ideas, but haven't seen it used anywhere though has a lot of fans.

      • by Tom ( 822 )

        I've seen it used in real applications, in fact I know a security-software company that went entirely to Rust.

        Adoption is largely slowed - I believe - by the incompletenes of the LAMP stack-equivalent. If Rust had something like Meteor or Symphony, it would take off. The webasm features are pretty impressive, and it's darn fast - I replaced some PHP backend calculations that took too long (30-60 seconds) with Rust and it went down to 2 seconds. Then I thought "at that speed, I can actually move it client-s

        • so now I can say "some guy named Tom on the internet knows some security-software company that he wouldn't mention name that went to Rust."

          I retract zero point five percent of what I said, LOLZ.

          • by Tom ( 822 )

            Pfft. Your statement was that you haven't seen it used anywhere. How's that different from my statement that I have seen it used somewhere?

            Or, you know, you could spend 20 seconds in Google and find:

            https://kerkour.com/blog/rust-... [kerkour.com]

            But even if you are too lazy, just on specific example is enough to prove an all-quantor statement wrong, so what about Discord? https://blog.discord.com/why-d... [discord.com]

    • by xack ( 5304745 )
      It’s a dependency for Gnome and Firefox now, which means most Linux distros are forced to include Rust.
  • Rust is appealing for writing components like drivers and compilers.

    So appealing that the Rust compiler is written in Rust itself.

Truly simple systems... require infinite testing. -- Norman Augustine

Working...