I think that C++11 and beyond will do quite well. Sadly here in the UK at least, it has lost vast swathes of the job market to C# (likely because of C++11 taking so long to appear) but there are still a few C++ jobs (for maintaining crusty MFC codebases) or a few that specifically mention C++11.
I myself think C++11 is a great language and daily write C++03 at work through gritted teeth.
As you say though, we'll see what comes about. It is only a language after all.
EDIT: And I will add that C++ does have the benefit of having loads of libraries available to it, including GUI libraries and bindings which makes development a breeze.
The very definition of static safety guarantees is that the compiler enforces them, and that's what makes them useful. C++ has great safety guarantees if written correctly - but if you can reliably write code correctly, you don't need safety guarantees in the first place!
> EDIT: And I will add that C++ does have the benefit of having loads of libraries available to it, including GUI libraries and bindings which makes development a breeze.
There are many libraries, but the important ones have mature bindings from other languages, or at least tools for generating them (e.g. Swig). That said, using them exposes you to the safety risks of C++, so you're often better off rewriting them (e.g. I worked on a Java project that initially used ffmpeg to handle some transcoding tasks - but as a result had to deal with bugs in ffmpeg that took down the whole JVM for particular inputs).
Good point though!
Sad about your JVM - did you not monitor the state of the process you spawned to handle transcoding? Did you end up fixing the bugs in ffmpeg?
When the set of actions that might violate the guarantees is small, circumscribed and easy to spot in code review and/or with automated tools this kind of approach works. But in C++ it feels more like today's best practices are tomorrow's unsafe constructs - it's like perl's "there is more than one way to do it", but additionally all but one of the ways are unsafe.
> did you not monitor the state of the process you spawned to handle transcoding?
That was my point - we originally tried to use JNI so that we could use libffmpeg as a library (and e.g. handle parameters and input/output as structured data rather than having to flatten them to a string command line and temporary file or pipe). But unfortunately if you do that you give up the nice guarantees of the JVM platform - e.g. a Java-native library will only ever affect its own thread, but a bug in a JNI library can take down the whole JVM. (We did ultimately move to a separate-process-for-transcoding model for exactly this reason)
> Did you end up fixing the bugs in ffmpeg?
We fixed specific bugs as we found them. It didn't feel like we were making a dent in the number there were though.
Agreed about the potential of Rust, it sidesteps most of these problems. Though it might introduce other problems of its own, only time will tell. I expect that Rust's future sore spots will include destructor leaks, the reliance on macros, and the tremendous complexity of traits. (Though of course I don't claim to have better solutions to those.)
> destructor leaks
> reliance on macros
> the tremendous complexity of traits
Yes, the Waterbed Theory of Complexity[1]. It can be useful to funnel complexity into specific areas where it's at least expected, and there may exist better mechanisms for dealing with it.
Right, I'm not saying C++ is perfect either. I feel like Rust made a wrong turn here: https://www.reddit.com/r/rust/comments/3404ml/prepooping_you...
> reliance on macros
I'm referring specifically to try!.
None of the proposed solutions mitigated this either. You will always be able to leak cycles. The difference was that some proposals made it possible to mark types as non-leakable, in which case they can't be placed in things which may potentially leak.
The fact that things will leak was never under question there. The decision to be made was on how safety should interact with it -- should there be a way for a type to rely on its destructor being run for the purposes of safety? The decision was that there shouldn't, and we ended up fixing two APIs which relied on destructors being run for safety, instead of adding a major language change.
Maybe the cleanest solution to the leakpocalypse would be to mark RefCell.borrow_mut as unsafe, because it's problematic in two separate ways (it can both panic and create cycles). That way the safe fragment of Rust would guarantee that memory leaks can't happen and destructors always run. That would fit with the spirit of Rust, which strongly prefers 100% guarantees to 99% guarantees. Though I guess that idea was judged too inconvenient for users, and I don't claim to know what users want.
One way to handle this is to have each type explicitly opt-in to saying they're concurrent-safe, but this is fairly annoying, as it requires a lot of boilerplate. Boilerplate that is mostly pointless in Rust, because its rules mean most types people define will be safe, and most types that aren't safe will be built out of existing types that aren't safe. OIBITs are proxies for "safe", and are designed to strict a balance, by basically following that rule (types made out of types implementing an OIBIT automatically impl that OIBIT too).
Moving on to your specific suggestion: RefCell isn't the only way to not run destructors, for instance, one can create ownership cycles with Mutex and RWLock in a similar way, and, more broadly, threads that dead lock (or live lock) will leak their resources, as would calling std::process::exit. There's also weirder/wilder things like the following: suppose Queue<T> is a multiple-producer multiple-consumer queue type, where any instance can act as both a producer and a consumer (typical for such types), then the following code creates an ownership cycle within the queue, and so won't run the destructor of X:
struct Msg {
x: X,
y: Queue<Msg>
}
let q: Queue<Msg> = ...;
let q2 = q.clone(); // another handle to the same queue
q.send(Msg { x: ..., y: q2 });
drop(q);
1) After some soul searching, it seems like the really important invariant to me is that all alive objects should be reachable from the stack(s) at any given moment. So I'm kind of okay with failing to run destructors due to deadlock or process exit, but not okay with leaking a cycle. Is that a sensible distinction, or is the situation even more subtle?
2) How do I make a cycle with Mutex and RWLock?
3) I don't completely understand the queue example, what exactly is the magic that allows self-reference?
I think that's a reasonable distinction, but, at least for deadlocks, I'm not sure it is enough to have all the guarantees one might want (particularly around multithreading/scoping). Then again, it might be.
> 2) How do I make a cycle with Mutex and RWLock?
The same as a RefCell, just call `.lock().unwrap()` and `.write().unwrap()` instead of `.borrow_mut()`. These two types are essentially the same as a RefCell, just with more synchronisation, and fewer panics. They can block and wait for another thread to finish, at the risk of deadlocks of course, while a RefCell is restricted to a single thread, so blocking would just dead lock a thread with itself, hence a panic resolves the situation better. In fact, other than this blocking/panicking distinction, a RwLock and RefCell are almost identical: .read == .borrow and .write == .borrow_mut.
Here's a demo which creates cycles that contain a type that prints in the destructor (demonstrating that they don't run): https://play.rust-lang.org/?gist=6ea16b859e22f57fee14&versio...
> 3) I don't completely understand the queue example, what exactly is the magic that allows self-reference?
This is also essentially the same as the core RefCell/Mutex example, replacing .borrow_mut()/.lock() with .send. An mpmc Queue<T> will be isomorphic to Arc<Mutex<VecDeque<T>>> (although unlikely to be implemented as such in practice). The key is that they will reference-count the book-keeping that needs to be shared among all handles (like the start/tail of the queue), which allows creating a reference cycle.
> I feel like Rust made a wrong turn here
> I'm referring specifically to try!
I think of things like the leakpocalypse the same way I think of security advisories like the Go one from a few days ago. Yeah, it looks bad on paper, but the odds of being affected by it in practice are so incredibly low that it's not worth worrying about.
It describes a (sketch of) a statically provable memory safe dialect of c++. A more detailed description is in one of the referenced papers by Herb Sutter.
Unfortunately the promised static checker is, as far as I know, yet to be released, and we will have to see how well it will work in practice and whether it is feasible to piecemeal add the safety annotations to an existing codebase.
Remember the Y2K problem and how those programmers in the 60s and 70s thought that by the year 2000, surely their code would have been either fixed or rewritten.
At most, C and C++ are "dying" in the same way COBOL is - for new projects, other languages might prevail, but there are still mountains of legacy code written in it that nobody dares touch...