I just wonder if it will become the language of choice for things like game development and embedded applications in the future, and I wonder if people are already starting to use it for these purposes, and I wonder why people so far choose not to, if indeed that is their choice.
Rust is good at solving certain scaling issues in large applications: Servo, the lead usecase for Rust, can safely take many parallelizing optimizations that would be unfeasible to debug anywhere else.
That does not make it a defacto winner for any other problem space. For games, for example, having to reason about concurrency is the status quo for most of the gameplay code regardless of the memory management system, and tightening memory only addresses a fragment of the problem space, because dynamic memory allocation is not a primary requirement(fixed sets of assets and fixed design constraints mean that a heavily static, early-binding approach to game coding works for most things, most of the time - so the difficult errors will tend to surface outside of memory management as an odd runtime behavior). [0]
As a drop-in "better C" it's not a great fit, either, because the focus is on making these in-the-large problems a top concern at all times. It creates friction in migrating to Rust, leaving the floor open for a smaller language that operates at the lowest levels of safety, doing its best to be both C-compatible and improve the parts that can't be addressed by leveraging or patching up the existing C ecosystem.
Zig is my top pick for a language that can address this niche, though it's still an early stage project.
[0] AAA-scale code can still benefit, of course. Most games aren't AAA.
Rust’s solution to concurrency is a hell of a lot more than just solving memory management. As long as you avoid `unsafe`, Rust statically prevents all race conditions. Rust also makes it so if you can parallelize something, then you’ve proven that it’s safe to parallelize it, and therefore you can parallelize complex systems in Rust that you simply wouldn’t have the confidence to do with other languages.
In my lab, we’ve been discussing it seriously for a while. We think it’s probably best-suited for a highly multithreaded environment which can’t be trivially parallelized. Until we need that in particular, C++ will most likely meet our needs quite well.
Another vote for Zig. I am intrigued with Rust, but don't get too far with it as with other languages, but understanding its mission statement is a lot more comprehensive.
The Rust Programming Language book is very well written, however, by the end of the book it feels like you are just learning the language with no stimulating examples.
I am using Zig, and making great progress with my personal projects, and look forward to being much more productive in the near future.
Jai is trying to fit that C space too. Similair ideas to Zig, but more aimed at the games industry. Curious to see which ends up gaining more traction (if either do, fingers crossed)
I work as a C++ programmer. I would love to switch to Rust, but:
(1) To my knowledge, it has only one implementation, which isn't surprising, given there is no spec, so basically there is nothing to reimplement. As @sircmpwn put it:
> Rust doesn't have a specification
> Therefore all Rust code is undefined behavior
I mean, if something isn't specified in the docs and the compiler changes its behaviour in this area, is it a bug? There is no spec, so nope, but your program may still start malfunctioning.
(2) It has a lot of features, looks very complex, and complexity is something I want to avoid after seeing how ugly C++ can get.
(3) For now, there are more libraries available to use for C++.
(4) I don't follow its development very closely, but, from what I've seen, it changes pretty fast for a programming language and it's not something I like (in programming languages).
So for now I will continue learning more Python and perhaps in the future I'll look at Rust again.
There is a second implementation of everything but the borrow checker.
> I mean, if something isn't specified in the docs and the compiler changes its behaviour in this area, is it a bug?
Since Rust is so strongly typed, we do have strong rules for many kinds of changes, even if there's no formal specification. That can only help with some things, but it does help a lot.
> it changes pretty fast
The key here is that the changes are additive, that is, we don't make egregious backwards incompatible changes. We do sometimes for things like soundness fixes, but even then, we have tooling to estimate the impact of breakage on the ecosystem, and have strategies for easing that pain. Most users report that their code never breaks, and virtually all of the users whose code has broken report that it was trivial to get building again.
> So for now I will continue learning more Python and perhaps in the future I'll look at Rust again.
Python doesn't have a specification either. It's also relatively complex (even if the code looks simple), and while it might not change fast, the big changes that were made weren't handled particularly well (2 -> 3).
The Rust folks seem to have learned a lot from other languages, both in terms of their successes and their failures. You can see this with things like Cargo, and how Rust editions are being handled.
I'm not saying don't learn Python, just that if you're willing to use Python, then I don't think your arguments against using Rust are particularly compelling.
Though I haven't programmed in it beyond toy problems, Rust is exciting because it actually has an answer to the question of "why would you use this instead of C/C++ for systems programming?" and the answer is memory safety, concurrency, and rich, no-cost abstractions. It also has a good story for interop with C.
Having an answer to that question is necessary, but not sufficient. There's also a lot to be said for being in the right place and the right time---who'd have thought in the early 2000s that Objective-C would suddenly become a hot language? Killer apps like the iPhone can make a huge difference.
It's still early days. Industry standard languages have lifespans on the order of decades; C is rougly 45 years old, C++ roughly 35 years old. I think Rust has a chance, but we won't really know until it's a decade old.
The two big ones for me (neither of which apply to games or embedded) are the lack of a stable ABI and the over reliance on cargo this causes. These two make rust more of a platform like c#/nuget and js/npm than a replacement for c and c++, no to mention the extra bloat and security issues they cause. I want my system software to work with the system, not add layers of duplication on top of it.
The rust community has no desire to address either of these.
What's the problem with a good integrated package manager? I mean, one can choose to not use it. Is it curated single-source libraries ala Boost/Qt you miss, or something else?
> What's the problem with a good integrated package manager?
The problem is that I already have a better one and things like security patches get back-ported to it. I get to make managing that a job for the distro maintainers but with cargo it's my problem. As a user I have absolutely no control or visibility of what versions of dependencies are in there.
If I choose not to use it then there's not much point to rust in the first place, I have to work with everything through c interfaces.
Then of course there's the binary bloat. All-in-all cargo is just putting developers needs before users.
You seem to be mixing up distro package managers and language package managers.
Distro package managers don't let you do versioning in any reasonable way, and they are OS-specific, so they are not good for versioning dependencies of a software project. In particular, if you want reproducible builds, you're out of luck.
> As a user I have absolutely no control or visibility of what versions of dependencies are in there.
Which is also true of header-only libraries for C, or vendored dependencies. While sometimes shared libraries are used by projects, it's certainly not the only way dependencies are handled in C/C++ land.
The only reasonable solution I see to combining a distro package manager with a language package manager is the nix package manager...if only it was more cross platform. As it is now, it only supports Linux and macOS.
I can’t use it my workplace because it doesn’t support platforms my product requires. (In addition to Linux and Windows, I have to support AIX, HP-UX, Solaris, and OS/400). If Rust were more portable/ported I could start to consider it. For now that means I’m sticking with C++, C, and Java which work all those places.
I'm in a similar situation. I am cautiously optimistic that "mrustc" can help in this area. Compiling rust to C++ seems like the right direction for the more esoteric operating systems and platforms.
My litmus test for Rust ergonomics is when they implement named arguments. They're still not there.
Rust does some things well, but too many times I've gone looking for a Rust-y way of doing something I can comfortably accomplish in C++, and found the answer was inadequate or convoluted.
There was some discussion of it on the "C conferences" thread a couple of hours ago. Steve Labnik posted some links to discussions around it's use at EA etc.
Personally I think it's a bit early for Rust to displace the incumbents there, but if any modern language has a chance, it's probably Rust IMHO. Consider one of the largest and most popular game engines right now (UE4), that's a huge codebase and rewriting it in Rust at this point doesn't make a lot of financial sense, even if it could technically be done.
It seems to making some inroads in the embedded space from what I can tell too, but rustc will need to have a wide range of architectures supported before it can replace C/C++ there too.
I'm waiting for native support for primitive int, ieee 754 binary float, and ieee 754 decimal float types in 32, 64, and 128 bits. Not classes. Not structs. Actual primitive, interoperable types like c and c++ have.
Yes, I'm dealing with binary formats containing binary and decimal floating point in various sizes. I also sometimes need to talk to C APIs that take _Decimal64 and friends. Rust's interoperability is hampered by the lack of basic types.
There is no language called C/C++. There is C, and there is C++. The answers are qualitatively different for the two languages, so conflating them, in any context, can only ever produce confusion, noise, and misery.
The answer is that C++ is replacing C anywhere C is not dug in too deeply -- mainly OSes conceived long before C++ stabilized, and specialized embedded environments where manufacturers are actively hostile to change. Rust is also replacing C, in the same places, but of course still overwhelmingly more slowly. In a few places, Rust is used where C++ would have been, such as in Mozilla's page rendering, but the difference between Rust's and C++'s expressiveness is not, generally, big enough to overcome structural drivers. Both are so overwhelming better in every conceivable way than C that only inertia maintains any remaining niches for C. It is just so overwhelming better to code Rust or C++ than C, and so much very much C, that there is no need for either Rust or C++ to see the other as competition.
In the future, Rust and C++ may come into competition, but today it is more like motorcycles vs tractor-trailers. (Back in the '90s Jonathan Schwartz compared C++ to another language, saying if the other was like a seaplane, C++ was more like a boat anchor with feathers.) C++ still has historical baggage Rust lacks, but that is changing. C++ is getting better very fast, so that Rust is chasing a moving target.
I love how people are pedantic with a term that the respective ISO members use on their official communication. Just go search the mailing lists and papers.
Oh, and then there was the "The C User's Journal" that got renamed as "The C/C++ User's Journal" when C++ started to be adopted across all C compiler vendors.
Practically C/C++ means C++ and sporadically C++ first and C second. When you see a job offer for a C/C++ programmer you can safely assume that nobody cares for the literal C part. It all depends on context, in this case I agree with you.
Having been an earlier C++ adopter, I have grew with the language and witness how it struggle to take over C use cases, and there are still areas where it isn't the case.
So from my point of view, for game development, until there is an engine comparable to CryEngine, Unreal, Unity, Godot, Rust will be playing catchup with productivity from C#/C++ workflows.
For embedded applications, even C++ struggles there, as there is a large community that won't move beyond C89 + language extensions + Assembly, no matter what.
C++ is able to get market share there, because some certification standards now require C++14, e.g. AUTOSAR, and there are OSe like ARM mbed, fully written in C++. So those devs have no choice when landing in such projects, either accept the language or move to somewhere else.
For general app development, Rust lacks the integration that C and C++ enjoy across XCode, Android Studio and Visual Studio for mixed mode debugging, integration into the official toolchain and GUI tooling.
For example, creating UWP/COM controls on Windows to be used from .NET applications and stepping through them with a debugger, or creating a native library on Android to be called from Java/Kotlin, while being able to debug it on device and track down a performance problem via the Android Studio monitoring tools.
Surely you can make it work, but right now, it makes what is already sometimes a hard task, even more complex.
I've been tempted to use Rust in my personal projects, but I have yet to find a reason. Even in complicated stuff, I usually write C++ code (not C) that needs few iterations to be without errors.
But I have good experience with C++ and concurrency...I haven't used raw pointers for example from 2006...I wrote my own smart pointer library which I used until all major compilers supported smart pointers (boost was always there as a back up).
That, and the lack of OOP in Rust, has made me avoid it so far.
I think Rust will shine in projects with a varying degree of experience in C++ development. It can certainly improve safety over the large programs written by large groups, because it's impossible that those large groups will be filled with extremely experienced programmers.
I used Rust for my toy project and I liked the concept of borrowing. For me personally it felt a little bit like crossing of C++ and Python - all static typing and, curly brackets and semicolons (I honestly like it) and growing number of packages available through cargo (which seems somewhat similar to pip, however still not very popular). All in all my toy project is not super complicated (although I think domain problem is quite interesting) but I found Rust fit for the purpose and quite enjoyable to use. I'm running on Linux only so I had no problems with cross-compilation (as some mentioned they had).
I am considering starting a project, and I am finding myself to be more likely choosing C++ over Rust. Lot of libraries like platform SDK, libs like skia, openssl, etc are c++ based. So by choosing the C++ I am having the consistent source code environment, that makes benefits in things like building, code editing and debugging.
A programming language exists within an ecosystem of libraries/developers/companies/jobs/... It will take a looooooooong time for Rust to match the huge size and breath of the C/C++ ecosystems. It might actually never happen.
Yes, some people will switch however I believe that they will exist in parallel. It's funny how there is so much overlap between languages (say Python & Ruby) yet both are still very popular.
Rust has a lot of good IDE options these days: https://areweideyet.com/
They decided to focus on the "Rust Language Server", which many IDEs use, rather than on one specific IDE.
That list counts vim and emacs as IDEs, and also includes in the list sublime text and vscode.
In the end the only minimum working product IDEs they list (no debugging, no IDE) are vscode, eclipse, visual studio, and intelij.
AFAIK Eclipse does not support rust. At best there's a plugin that adds some support, but last time I've checked it failed to work on my setup. That doesn't leave many viable options on the table.
That does not make it a defacto winner for any other problem space. For games, for example, having to reason about concurrency is the status quo for most of the gameplay code regardless of the memory management system, and tightening memory only addresses a fragment of the problem space, because dynamic memory allocation is not a primary requirement(fixed sets of assets and fixed design constraints mean that a heavily static, early-binding approach to game coding works for most things, most of the time - so the difficult errors will tend to surface outside of memory management as an odd runtime behavior). [0]
As a drop-in "better C" it's not a great fit, either, because the focus is on making these in-the-large problems a top concern at all times. It creates friction in migrating to Rust, leaving the floor open for a smaller language that operates at the lowest levels of safety, doing its best to be both C-compatible and improve the parts that can't be addressed by leveraging or patching up the existing C ecosystem.
Zig is my top pick for a language that can address this niche, though it's still an early stage project.
[0] AAA-scale code can still benefit, of course. Most games aren't AAA.