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.
(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.
> 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.
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.
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 rust community has no desire to address either of these.
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.
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.
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.
https://news.ycombinator.com/item?id=18505307
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.
Rust's primitive types such as i32, u32, u8, f32 are interoperable with foreign functions.
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.
C/C++ is just an abbreviation to C and C++.
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.
Doesn't it supposedly have great interop capabilities?
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.
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.
I'm not an Eclipse user, but in my understanding, it's grown quite a bit since then.
https://www.eclipse.org/org/press-release/20180627_new-photo...