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.
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.
Rusty savings. (Score:4, Informative)
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?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
There are legitimate criticisms of Rust. Performance isn't one of them.
Re: (Score:2)
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
Re: (Score:2)
I would be fascinated to see your links to benchmark results.
Re: (Score:2)
Re: (Score:2)
Appears to be no benchmark content whatsoever in your link. Sorry, got to regard your comments as unsubstantiated. More in the realm of speculation.
Re: (Score:3)
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
Re: (Score:3)
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
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
There's no argument detected. You appear to be rambling.
Re: (Score:2)
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.
Re: (Score:2)
Re:Rusty savings. (Score:5, Informative)
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.
Re: (Score:3)
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
Re: (Score:2)
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]
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
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]?
Re: (Score:2)
You focus on writing clean code and let the compiler deal with making it fast, like it should be.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Plus they are now more implementations of compile time safety inspired by Rust without having undergo such a limited language for them.
Re: (Score:2)
Re: (Score:1)
Re:How about no (Score:4, Insightful)
That seems a tad bit childish and even petulant. Rust's advantages as far as memory safety are likely why people like Linus and Zuckerburg are interested in it. Surely you can evaluate the language based on its merits, and not because you don't like one of the company's looking at adopting or promoting it.
Re: (Score:1)
I suppose if Linux is going to become less portable and only available on a few processor types Rust is the way to go.
Where's the tarball, so I can build it on my Mac SE/30 that runs NetBSD?
Re:How about no (Score:4, Informative)
As Linus says, by definition, the kernel has to be unsafe code, because it lives at the level where there's no ring protection or easily available virtual memory or other protections we're used to in userspace. The kernel is the thing that maintains all that and so is unsafe by definition.
Rust's ownership model also conflicts with the kernel, because the kernel, again by necessity, must use a lot of shared memory to reduce communication latency between various parts of it.
Re: (Score:2)
By definition, the kernel has to include unsafe code. That is not the same thing as saying that all of the kernel has to be unsafe code. The same is true with shared memory.
That is the premise of Rusts safety and also it's ownership model. Most of the time it is enough; when it isn't you can step outside of it, but you have to do so explicitly. The unanswered question is, if we were to rewrite linux in Rust how much of it would have to be marked as unsafe. If the answer is "most" then you gain little indeed
Re: (Score:2)
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
And what it says about raw pointers in particular to Rust:
Are allowed to ignore the borrowing rules by having both immutable and mutable pointers or multiple mutable pointers to the same location
Aren’t guaranteed to point to valid memory
Are allowed to be null
Don’t implement any automatic cleanup
Not a single kernel that doesn't do a bunch of these to remain performant, or just a result of being in a naturally unsafe - no rings, no virtual memory - environment. Any work you do to wrap functionality that deals with raw pointers to kernel
Re: (Score:2, Funny)
This just in - Barbara Boxer states her support for the Rust Programming Language [lmgtfy.app].
Needs a second compiler, cross platform support (Score:4, Interesting)
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.
Re: (Score:1)
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.
Re: (Score:3)
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.
Re: (Score:2)
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.
Rust only exists... (Score:3)
...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.)
Re: (Score:3)
> 6402 assembly
I'm assuming that was an off-by-one key typo? ;-)
i.e. 6502 assembly
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:1)
Re:Rust only exists... (Score:5, Funny)
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.
Re: (Score:2)
[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
Just write assembly drivers....No kidding .NET too (Score:1)
Re: (Score:2)
Write in FORTH for that close to the metal feeling.
Re: (Score:2)
Write in FORTH for that close to the metal feeling.
Well that makes me nostalgic. Syntactically significant color for the win.
RustemD (Score:2)
Re: (Score:3)
> 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)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
> 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,
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
If they did that it wouldn't be C anymore.
Rust (Score:3)
Re: (Score:3)
for what? Language has some great ideas, but haven't seen it used anywhere though has a lot of fans.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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]
Re: (Score:2)
So appealing (Score:2)
Rust is appealing for writing components like drivers and compilers.
So appealing that the Rust compiler is written in Rust itself.