I work for Faraday (.io, not the car folks), and we use Rust in production. I personally suspect that Rust will continue to grow in popularity.<p>We've been really happy with Rust. Our Rust programs tend to be fast and resource efficient, and they tend to have few bugs (and most of those are cases of misunderstanding the problem or the spec).<p>The learning curve tends to be pretty rough for the first week or two, but you can reduce that by pairing with a more experienced Rust developer. And after that, it's pretty smooth sailing. Certainly any C++ programmer should be able to make the leap fairly quickly--it helps to have used at least one non-GCed language.<p>The third party library situation is better than you might think for a young language (the database clients, RabbitMQ clients, HTTP clients, compression, etc., are all basically usable), but I normally expect to fill one or two library gaps per project.<p>Overall, I find it difficult to articulate why I like Rust. It's pleasant to write (now that I know how), it runs fast, the CLI tools are pretty solid, and has enough abstractions to keep the boilerplate in check. And I can throw cluster-sized workloads at it and trust it to work, and work fast.
Whatever the answer is, you probably will not find it here. From an historical perspective, the success a language seems to have very little correlation with the vague notions of quality that we language geeks think are important. And it seems that the HN echo chamber forgets that.
Rust has to stand the <i>true</i> test of time -- the test where 5-10 years-old codebases written in Rust are still being maintained. Someone who's literate in programming language <i>theory</i> can evaluate the design decisions in Rust and say "it looks good" (or not), but in order to determine whether Rust is actually good for building and maintaining large, complex software systems for long periods of time, there's no metric like really doing it.<p>I think at some point, Rust will have enough tooling that people will try to start using it for graphics and videogames -- the applications where C and C++ shine but their "safer" rivals Fortran and Ada can be a headache to work with. It's in this arena -- where Go is too slow -- that Rust will really sink or swim. And it has barely even started to make headway. Maybe GNOME 5 will be written in Rust, or maybe the GNOME 5 developers will try Rust and conclude it's not suitable. Whoever they are, they haven't even started yet.
I had great hopes for Rust as the future of systems programming, but they've decreased over time. Parts of the language are just too cute.<p>The borrow checker was brilliant. Any future language that doesn't use garbage collection will have to have one. That was the big advance in Rust.<p>But the object system (yeah, they're called structures and traits) is too weird. The enum approach to variant records is too weird. The error handling is too weird. The half-functional style is too weird. The widespread use of closures for simple stuff is too weird. There's too much unnecessary originality. Trying to port something from another language to Rust is difficult because Rust's ways of doing things are so different from other languages.<p>I have the feeling that Rust is destined for a niche like Haskell - cool, but not mainstream. That's sad. I really thought early on that Rust meant the end of the decades of hell from the lack of memory safety in C and C++. But that's not happening.<p>The Go crowd knew when to stop. The Rust crowd didn't.
The Rust ecosystem has lost sight of the forest for the trees in my opinion. I highly agree with Graydon's opinion in "Rust is mostly safety" [1] that it's raison d'être is memory safety and concurrency in the systems space. But strangely a significant amount of time is being put in to making it usable for other tasks. I think this has to do with the different cultures between C/C++ developers versus other developers, namely that developers coming from web development are younger and more used to jumping around to new languages and frameworks.<p>With it's borrowing semantics and steep learning curve, Rust will never gain significant market share in the world of web development. And why should it? Time to market matters more than speed. It's much easier to ramp up new hires on a C# or Go code base than on a Rust one. And the borrow checker will always create friction for people new to the language. As someone with a C++ background, it still took me over a month before I stopped fighting with the borrow checker and with lifetimes. I can't imagine how long it would take to get a completely new programmer up to speed.<p>[1] <a href="http://graydon2.dreamwidth.org/247406.html" rel="nofollow">http://graydon2.dreamwidth.org/247406.html</a>
I want to believe. I love Rust. I feel like Rust is the language I've waited for all my life.<p>Yesterday there was a story about Rust here on HN: "Programming ARM Cortex-M Microcontrollers with Rust." Among the replies was a complaint; someone couldn't figure out how to write a static buffer and was discouraged. Someone else provided an example of how to do this. Finally, another person noted how unfortunate the solution was. Here is the code, reworked by me just a little:<p><pre><code> use std::io::Write;
use std::str::from_utf8_unchecked;
static mut S1: [u8; 17] = [0; 17];
fn main() {
unsafe {
write!(&mut S1[..], "Hi: {}", 5).unwrap();
println!("string: {}", from_utf8_unchecked(&S1[..5]));
}
}
</code></pre>
There are three distinct reasons why everything has to be "unsafe." Unless you have a lot of experience with Rust you are NOT going to figure that out until you've banged your head against the compiler for some time doing your level best to minimize the lines of code you've wrapped in unsafe, and then finally surrender.<p>That is a lot of friction. I know (as in I understand with precision) the reasons for this and they're entirely legitimate. But damn... the pain is just more than the bulk of the world is ever going to tolerate. You can do the same task with zero friction in C/C++ and go fast/be small, or you can do it with a "managed" language with zero friction and handwave at the bloat and cycle eating cache killing GC, or you can don the hair shirt, focus on your breathing to keep the panic at bay and use Rust.<p>It is inescapable human nature that the "mainstream" will avoid the latter.
It does keep rising in popularity, but is that coming from folks actually using system languages like C, C++, Ada, and Forth? I'm guessing only a portion. There's a difference between a web developer using Rust enthusiastically for hobby projects and a seasoned C coder switching to Rust for a professional job. In fact, a lot of the projects I've seen in Rust (ex: Dropbox) are commonly being done in Go as long as the GC isn't an issue.
Most C++ developers won't easily develop systems in Rust because of lack of well-known libraries and a stable ecosystem(profilers, static analyzers, concurrency tools, many skilled and mediocre developers, etc). C++11 and subsequent versions have a good amount of memory safety(though not as safe as Rust).<p>Rust is a modern language with very good concepts and features. It's quite complicated to learn.<p>My answer is it will be a good language, but won't be a top language.
System76 is using Rust now for automated testing and firmware flashing. I wrote these projects in rust, and I enjoy using it, can't say much about the other engineers.
My feeling is that Rust (and/or Go) will probably supplant Java (and/or C#) in the coming age, just on the basis of the user experience alone. This past week I wasted several hours trying, and failing, to get a simple Java app up and running. Rust (and Go) have such a better end user experience that I can't see them not winning. Firing up a single executable is miles better than installing a run time, then tweaking the config to make it work, then trying to find out where it stores log files, then tweaking it again when it fills up memory, etc.<p>Give me a single, self contained, executable any day!
I think it's important to consider the implications if Rust <i>doesn't</i> become a mainstream programming language.<p>I'm not shy about my dislike of Rust. I like C, I don't think avoiding buffer overflows and memory errors is that hard, and I chafe at the idea of a language I dislike aesthetically taking over systems programming.<p>But even I have to admit the arguments for using C instead of Rust are niche. Sure there's probably always going to be some instance where C makes sense technically, but if we could wave a wand and convert the world's C/C++ code to Rust, we'd immediately fix millions of memory errors and data races. It's impossible to overstate that benefit.<p>Think of the things the Rust team has to deal with:<p>"Is Rust a good web language?"<p>Is C or C++? Is Ocaml?<p>"Is Rust a good language for an OS?"<p>Is Python? Is JavaScript?<p>"Is Rust too big?"<p>Is C# or Java? Rust is a pretty small language, both in terms of features and implementation size.<p>"Is Rust powerful enough?"<p>Is Go? Go deals with this all the time ("Go ignores decades of PL research"). Rust's feature set is pretty good, but more importantly it's well thought out.<p>"Is Rust fast enough?"<p>Is Java? Is C#? Is Go?<p>"Does Rust compile fast enough?"<p>Does C++? Does Clojure?<p>"Will your Rust program be memory safe and free of data races?"<p>It sure will be. This is a monumental achievement. Your options for a memory-safe language without GC are... Rust and Ada?<p>"Does Rust have a good concurrency/parallelism story?"<p>Rust has one of the best, actually. It doesn't use segmented stacks so it doesn't achieve the M:N performance of Go, but it has memory and data race safety, OS threads, and futures, so no problem.<p>"Is Rust too hard?"<p>Honestly, programming is hard, other languages just let you ignore it. There's an example about manipulating a string as a global array in this thread somewhere, which is not really something you should do, and the argument was "this was wildly difficult". It is, yeah, because safely managing concurrent access to a global, bounded section of memory is wildly difficult.<p>Again, I'm not a Rust fan and I sort of can't believe I'm writing this. But look at what Rust has:<p>- memory and data race safety<p>- scripting language ergonomics (after you internalize the borrow checker)<p>- the speed and memory usage of C<p>- a low surface area<p>- advanced features<p>- great community outreach and documentation<p>- familiar structure (as opposed to something like Erlang or Haskell)<p>If a language like that doesn't succeed, you have to start wondering what will.<p>My personal belief is that it is succeeding, but I think success looks a lot different than most expect: new projects that need a systems language are far more likely to be written in Rust than in C/C++.
If "functions as a service" (AWS Lambda) takes hold, I think Rust will be a popular server language since you'll need services with almost no startup/warmup time.
I would say so far, yes. I would say it's pretty "mainstream" already with many companies using it in production, including Mozilla.<p>As big as C++/C? Too early to tell for that.
Not too sure what is meant by "mainstream" but I can see Rust getting a foothold in certain industry, such as medical, automotive or aerospace. To get there, it will need to be mature and be stable significant enough. It will also need a big player to take that first step and prove it in production.<p>Imagine if Ford mandates its suppliers to use Rust for the software in its car and it faced little problems after a few years out on the road.
Probably. But why do you care? If you like it then use it and build something. If you don't like it, use something you do like and build something.
I think it has a fair chance (Go is a "systems" language and grew very quickly). I also believe you'll see it pop up in unikernels as well. Why, you ask? Because there's always 1 person that starts a project that gets traction.<p>I don't see it growing and replacing C++ though. I don't think there's much incentive post C++11 to really consider porting anything (even small things) over. Most of the features Rust gets praised for are either: (1) Ridiculous - if you need segfault protection, you're a bad programmer (CLARIFICATION: if you act like segfault protection is some majorly useful feature, you're an imbecile who must also think writing C/C++ is like disarming a bomb - nonsense; give me a real argument for Rust that isn't: insignificant, badly contrived, already in C++, etc. - you can't convince a generation of systems programmers to drop everything to move to Rust without this). Let's be honest, you don't segfault unless you're doing something idiotic. I've not segfaulted in the past 8 years in anything but assembly. Or, (2), things I've been using in C++ for the past 4 years.<p>Rust will definitely end up in these areas I believe but I just hope that it's not some horrible binding to a C/C++ library or something. I think backwards compatibility and current dependencies is a big thing.