Your point might make sense for web facing software because programs where lives are actually at stake are written in Ada or a subset of C with rigorous static analysis and engineering processes.
Now, it can't be denied that C and C++ are weak from a security perspective and that they should be avoided for network software as much as possible. But the problem with your take is the subtle implication that Rust is "safe" (not just memory-safe) when in fact there is no empirical evidence or track record of Rust being successfully used in anything remotely mission-critical. I mention this because you brought up the bridge example when it is also possible that due to language complexity that the new "bridge" built in Rust would turn out to be even fragile (but just memory-safe).
Just the other day, there was a Rust GUI library posted here. The library uses a convoluted event handling mechanism of passing enum values as messages and additional book-keeping burden instead of straightforward closures just so that the compiler can prove the code is safe (just memory-safe, mind you). It is possible that because of such contortions required to pass the compiler, Rust could fare worse in the "general correctness" area[1]. It is just that we don't know yet. Even the particular safety issue that is mentioned in the GP comment could be solved by having built-in slice types and mandatory bounds checking (like Zig/Go/D). As usual, C/C++ have terrible defaults.
Again, I agree that there is a need for secure alternatives to C and C++. But the contention is whether Rust is that. Even Rust is actually far from optimal in the "safe systems language" space. There might be languages in the future that are as fast as Rust but more ergonomic. Microsoft Research, for example, is creating a research language named Verona[2] that aims to be memory-safe and concurrency-safe. There are also other attempts like Vale[3] that aim at this space. It is premature to think that Rust is the final evolutionary step in the landscape of systems language and suggest for everything to be moved to Rust ASAP. It often appears like reckless fanaticism.
> But the problem with your take is the subtle implication that Rust is "safe" (not just memory-safe) when in fact there is no empirical evidence or track record of Rust being successfully used in anything remotely mission-critical.
An application built from the ground up in a language like Rust is going to have fewer vulnerabilities than the same application built in C++. I say this as a person who loves C++ and is intimately familiar with the state of the art of securing C++ applications. I am not proposing an immediate rewrite of everything, though I do personally believe that the "well a rewrite will just introduce more vulns" concern is overblown. I expect papers in ICSE in the not to distant future to be able to validate one of our views.
Rust is not flawless, not even close. There are other alternatives and there can even be new languages in the future, but it has the most mindshare and it is an alternative today. For many years, people would simply say that there was nothing that could compete with C and C++ for systems programming. Rust very nearly handles all of the common use cases. But... I didn't even really mention Rust in my post so I think it is especially difficult to call me an evangelist for it.
Like it or not, ideas in research languages take ages to filter into real world ecosystems. My PhD is in the intersection of static analysis and security. I love this research. But the honest truth is that waiting for MSR to produce the path forward is not a winning strategy. Languages need ecosystems and I think it is more likely that the future will come from industry than directly from academia.
> the subtle implication that Rust is "safe" (not just memory-safe)
It's not a "subtle implication" it's a fact that Rust is also data race free and thus concurrency safe in the same sense you're attributing to Verona, although for very different reasons - it can't introduce data races. Verona, unlike Rust, is not in fact a production system, it's an academic toy for pondering new ways to approach concurrency. Perhaps ten years from now its findings will influence future Rust development.
It's certainly interesting that we're still at the place where people are going, "This is only better if you can't afford GC", when even Java is markedly less safe than Rust since it doesn't prevent data races. (Yes there is ConcurrentModificationException for this, no Java doesn't promise to raise this Exception, and if it happens that might already be too late).
No, that is why I wrote "subtle implication" there. Unfortunately on online forums, the term "memory-safety" (which is a well-defined term in computer science), is nowadays almost always used in contexts of Rust evangelism. I would be very surprised if the GP's actual intent was that Zoom must have been written in a garbage collected language and not Rust. The wider context of this discussion at all is that whether memory-unsafe languages (ie., C/C++) must be made illegal with the implicit suggestion that Rust must be pushed as the alternative. If C/C++ is made illegal (because "memory-unsafety"), then guess what would be the legal alternative if you can't afford GC overhead. Moreover, for people not using C/C++, the question of memory-safety/unsafety doesn't even arise in the first place.
> But the problem with your take is the subtle implication that Rust is "safe" (not just memory-safe) when in fact there is no empirical evidence or track record of Rust being successfully used in anything remotely mission-critical.
If you don't need the performance characteristics or OS-level interaction offered by systems languages, then please use an interpreted language. Please please please please please. But there aren't a lot of new projects started in C or C++ that fit this, since people have known for decades that using something else will be better if you don't need the specific features offered by systems languages.
> The wider context of this discussion at all is that whether memory-unsafe languages (ie., C/C++) must be made illegal with the implicit suggestion that Rust must be pushed as the alternative.
I never said this and it would be wildly ridiculous for me to suggest this. I mention Rust elsewhere to describe poorly written legislation, not to say that legislation must demand that everybody bow down at the feat of the Rust community and donate their first born child to the borrow checker.
Fair enough. I felt compelled to post in this thread because I've seen the "ban unsafe languages" sentiment expressed several times here and on Reddit before (especially on r/rust I remember reading some comments that had a hostile tone written by people who were serious about it). Your initial comment in this thread resembled one of those.
I think you've misunderstood why I mentioned Verona and Vale though. It is to challenge the notion that there could not be any other language than Rust that could be more ergonomic but with slightly different trade-offs. Moreover, I agree with your point regarding the ecosystem.
That is a neat attempt at making it appear like I am somehow deluded and am imagining Rust evangelism. The person I replied to made a comment down thread that literally states that Rust must be given a free pass despite `unsafe` blocks on the face of such legislation against unsafe languages. Sounds completely illogical to me.
You can disable security features in java as well. Elsewhere, you mention GCed languages as an alternative. Would it be appropriate for me to assume that you are a java evangelist and then criticize you for not considering the harm that can be caused by turning off stack inspection? That's what you are doing to me.
The fact that the default is safe matters. It matters a lot. Heck, if you want to use C++ with a sound static analysis tool then I'd support doing that and I'd hope that legislation would support that too - but I think you'd be working 10x as hard as really necessary.
Yeah, I'm literally saying you are deluded and imagining things. The post you replied to mentions multiple GC and non-GC languages. That you also have a bad opinion about unsafe isn't really important.
Throwing ad-hominems at people criticising your language is not a good long term strategy, though it might appear to work for a while.
Not only there was not any "mentions multiple GC and non-GC languages" in the comment I replied or in the parent comments (except for single mention of C++), I also don't get why I have "bad opinion about unsafe" (and where I claimed it is important?). Such a friendly community. Now I see why people don't engage with Rust evangelists. Lesson learned. Anyway, have a nice day!
> To have GC where it makes sense and doesn't add too much overhead but allowing non-GC objects that require a bit more care and where you know you need to free memory yourself or using some basic smart_ptr-style tracking object?
D is designed exactly like that. In fact, using value types and smart pointers (using `typecons`) is kind of required if you want to keep GC pauses tolerable. On the flipside, a simple GC means no additional overheads like write barriers or remembered sets. Additionally, a borrow checker for D has also been in development (I have not personally checked it out to comment on it though).
One thing that helps OCaml here is that it requires definitions to precede usage (like C/C++). Go and most other languages don't have this requirement. Perhaps, this results in faster symbol table lookups. Moreover, OCaml boxes everything and doesn't produce monomorphized code for generic types. OCaml's code generation is also much simpler than the likes of LLVM or GCC.
> Shared ownership is code smell to me regardless of the language
This is an unsubstantiated claim. If Rust makes something hard, that doesn't automatically make it universally bad. Nearly every large Rust code base I've seen uses reference counting (both `Rc` and `Arc`) a lot. Moreover, it is not practical to write general-purpose code avoiding both GC and RC because the need for shared ownership will inevitably crop up at some point. So ruling it out as code smell is a bit dogmatic.
It is also worth noting that ownership semantics is one approach (among others like GC) to memory management. In future, more languages will have some sort of ownership semantics along with GC. Nim's ORC is currently a good example.
This is actually funny because unlike C++, Rust doesn't have true immutable types. Instead Rust restricts mutability in two ways. One is immutable bindings, and the other is the shared references. Your `unique_ptr` is example is how it ought to work actually. That way you have the ability to parameterize by mutability which Rust cannot.
To be more clear, in Rust, the `mut` you see in bindings (like `let mut blah = ...`) is wildly different from the `mut` in `&mut T`. There was discussion on whether the latter should be renamed to `uniq` (because `mut` is misleading). In any event, Rust lacks `const` types. There is no `const T` like in C++.
So something like this is impossible,
std::vector<const int> vec;
You can't have just the elements of a collection to be immutable like the above example in Rust.
Secondly, a value of a type `&T` can be mutated internally (aka interior mutability). A function taking a `&T` type and mutating it behind the scenes is very whacky. AFAII, interior mutability exists only to trick the borrow checker using the `*Cell` types (which use unsafe internally BTW).
It is a pity that none of the replies to this comment has actually clarified your doubts...
Assuming the absence of `const_cast`, C++'s `const` ensures that a data of the particular type doesn't get modified. That's it. Rust on the other hand, tracks and restricts aliasing. This means you can't get both a constant and non-constant reference to an object or anything owned by it (more precisely anything transitively reachable from it). This is helpful in preventing issues with invalid pointers (like iterator invalidation). For instance, if you have already borrowed an iterator (which is essentially a reference) you can't issue mutable operations on the vector (issuing mutable operations entails a mutable borrow), and that could potentially reallocate the backing memory of the vector. This property is also useful for preventing multiple writes to the same location in a multi-threaded application, making programs adhere to the single-writer principle by-construction.
The downsides are that you might sometimes need to contort your code or your program architecture or perform mental/type gymnastics to write some trivially safe code or even use unsafe (or else lose performance) to satisfy the borrow checker.
Now, it can't be denied that C and C++ are weak from a security perspective and that they should be avoided for network software as much as possible. But the problem with your take is the subtle implication that Rust is "safe" (not just memory-safe) when in fact there is no empirical evidence or track record of Rust being successfully used in anything remotely mission-critical. I mention this because you brought up the bridge example when it is also possible that due to language complexity that the new "bridge" built in Rust would turn out to be even fragile (but just memory-safe).
Just the other day, there was a Rust GUI library posted here. The library uses a convoluted event handling mechanism of passing enum values as messages and additional book-keeping burden instead of straightforward closures just so that the compiler can prove the code is safe (just memory-safe, mind you). It is possible that because of such contortions required to pass the compiler, Rust could fare worse in the "general correctness" area[1]. It is just that we don't know yet. Even the particular safety issue that is mentioned in the GP comment could be solved by having built-in slice types and mandatory bounds checking (like Zig/Go/D). As usual, C/C++ have terrible defaults.
Again, I agree that there is a need for secure alternatives to C and C++. But the contention is whether Rust is that. Even Rust is actually far from optimal in the "safe systems language" space. There might be languages in the future that are as fast as Rust but more ergonomic. Microsoft Research, for example, is creating a research language named Verona[2] that aims to be memory-safe and concurrency-safe. There are also other attempts like Vale[3] that aim at this space. It is premature to think that Rust is the final evolutionary step in the landscape of systems language and suggest for everything to be moved to Rust ASAP. It often appears like reckless fanaticism.
[1]: There is, in fact, few "anecdata" of Rust being less reliable: https://news.ycombinator.com/item?id=24027296 https://dev.to/yujiri8/it-seems-like-rust-software-us-bad-hk...
[2]: https://www.microsoft.com/en-us/research/project/project-ver...
[3]: https://vale.dev/