Aside from game dev, Rust is being used in quite a lot of green field work where C++ would have otherwise been used.
Game dev world still has tons of C++, but also plenty of C#, I guess.
Agreed that it’s not really behind us though. Even if Rust gets used for 100% of C++’s typical domains going forward (and it’s a bit more complicated than that), there’s tens? hundreds? of millions (or maybe billions?) of lines of working C++ code out there in the wild that’ll need maintained for quite a long time - likely order decades.
struct A {
name: String,
owned: B
}
struct B {
name: String,
}
you can't have a writeable reference to both A and B at the same time.
This is alien to the way C/C++ programmers think. Yes, there are ways around it,
but you spend a lot of time in Rust getting the ownership plumbing right to make this work.
Now it may take you a while to figure out if you've never done Rust before, but this is trivial.
Did you perhaps mean simultaneous partial field borrows where you have two separate functions that return the name fields mutably and you want to use the references returned by those functions separately simultaneously? That's hopefully going to be solved at some point, but in practice I've only seen the problem rarely so you may be overstating the true difficulty of this problem in practice.
Also, even in a more complicated example you could use RefCell to ensure that you really are grabbing the references safely at runtime while side-stepping the compile time borrow checking rules.
It's kind of crazy that OOO is sold to people as 'thinking about the world as objects' and then people expect to have an object, randomly take out a part, do whatever they want with it and just stick it back in and voila
This is honestly such an insane take when you think about what the physical analogue would be (which again, is how OOP is sold).
The proper thing here is that, if A is the thing, then you really only have an A and your reference into B is just that, And should be represented as such, with appropriate syntactic sugar. In Haskell, you would keep around A and use a lens into B and both get passed around separately. The semantic meaning is different.
I recently had this problem is some rust code. I was implementing A and had some code that would decide which of several 'B's to use. I then wanted to call an internal method on A (that takes a mutable reference to A) with a mutable reference to the B that I selected. That was obviously rejected by the compiler and had to find a way around it.
Rust depends on C++, until people cut their compilers lose from LLVM, GCC, and other C++ based runtimes, it is going to stay with us for a very long time.
That includes industry standards like POSIX and Khronos, CUDA, Hip and SYCL, MPI and OpenMP, that mostly acknowledge C and C++ on their definition.
There's a growing group that believes no new projects should be started in C/C++ due to its lack of memory safety guarantees. Obviously we should be managing existing projects, but 1973 is calling, it's time to retire into long-tail maintenance mode.
I've programmed C++ for decades and I believe all sane C++ code styles disallow multiple inheritance (possibly excepting pure abstract classes which are nothing but interfaces). I certainly haven't encountered any for a long time even in the OO-heavy code bases I've worked with.
What does this mean? There doesn't seem to be a popular alternative to C++ yet, unfortunately.