I am so hyped. I work on embedded devices that run QNX. We have huge, lumbering C++ codebases. For the past couple of years, I’ve been building Rust skills and tooling. This stuff now runs on QNX. Not only will this make our systems safer and more reliable, it will also save us so, so much time as safe Rust cannot cause memory corruptions or segfault and it almost never leaks memory. All of this with the same performance as C++.
I wouldn’t try to sell rust to the team/org using that particular claim. The so called modern c++ leaks memory as often as rust. It’s much better to focus on claims that will be very visible easy to verify, like prevention of memory corruption, data races and undefined behaviours when convincing others :)
I say “almost never leaks memory” because technically speaking, safe Rust does not guarantee freeing all the memory. In practice, however, memory leaks in Rust are extremely rare due to lifetime management at compile time. It pretty much never happens because the compiler will complain if you mismanage the lifetimes of your objects. You automatically do it right because the language deliberately makes it hard to do it wrong.
This is in stark contrast to C++, where it is indeed true that std::unique_ptr (etc.) cleans up automatically, but the language does literally nothing to prevent you from just allocating memory willy-nilly and not freeing it.
Saying that modern C++ leaks memory just as often as Rust is like saying that if you always brake carefully and in time, you travel just as safely as if you wore a seatbelt. Which might technically be true, but it does not reflect reality because humans make mistakes.
A very easy way to leak memory in Rust is to have a cyclical reference with an Arc without having the other side as a Weak. This makes building classic Java style trees a bit cumbersome, if you need to traverse in both directions.
A good structure is to just use flat vectors for your tree, but if you come from Java, cyclical reference counting is a quite common leak to make.
I don’t know what is your experience with both languages, but as far as I’m concerned allocating a pointer and losing track of it is not the typical leak that I had to deal with (more common in c++ but possible in safe rust). In fact I had to fix a leak caused by incorrect reference count in Arc due to bug in unsafe part using MaybeUninit last week 🙃
In my experience, most of the time the reason for constantly increasing memory usage (both rust and c++) is some long lived set or map that someone forgot to remove entries from. Since such space leaks are much more common and are equally likely in both languages, I wouldn’t try to sell rust as leaks preventing language.
This is in big contrast to stuff like preventing use after free and other UB - I’m writing rust professionally for last 3 years and I haven’t yet had to deal with any memory corruption, or data race. Which were a recurring issues when I was working in c++ codebases previously.
I don’t know what is your experience with both languages, but as far as I’m concerned allocating a pointer and losing track of it is not the typical leak that I had to deal with
Interesting. That is precisely the type of leak that I most commonly encounter in C++ and pretty much never in Rust.
In my experience, most of the time the reason for constantly increasing memory usage (both rust and c++) is some long lived set or map that someone forgot to remove entries from.
I’m talking about leaks where you lose or drop the pointer/handle to the resource. Of course there’s always the “endlessly growing map” kind of leak. This kind of leak cannot be prevented by any language because the programmer deliberately grows the data structure, which is an entirely different class of leak which is way easier to detect because you still have a handle to the data structure.
I agree with you that the main benefit of Rust is the safety that comes from the absence of memory corruptions and data races. And yes these issues appear in pretty much every non-trivial C++ code base no matter how skilled the programmers are.
At least the spec and the actual compiler are here. I’m guessing there’s probably documentation that Ferrous Systems/AdaCore clients also probably get access to.
You got it about right. The current answer for the repository is currently “no”, though. The reason is more that it would make our work (which includes undisclosed ports to other operating systems, things that need legal agreements like regressions tests, etc.) much harder and we’re a team that needs to look after their resources. However, we upstream our patches to the compiler and LLVM, things like the documentation. We have other things around open source in the back of our head, but I’d like to speak when they are well-formed :).
If you are looking at ferrocene/rust, that’s the repos we use for patching upstream, it’s just way easier to go public<>public and shows where the patches are coming from.
Hey, thanks heaps for that explanation - I really appreciate it. It’s great you’re planning to upstream as much as possible and also maintaining your spec in the open, that’s fantastic.
I can also appreciate that you’re in awkward place between “Rust development culture” and “automotive/industrial embedded development culture” where these cultures may have very different attitudes to open source. I’ve seen enough NDA-encumbered forks of old LLVM versions and the like to understand some of what’s lurking in there. :)
I am so hyped. I work on embedded devices that run QNX. We have huge, lumbering C++ codebases. For the past couple of years, I’ve been building Rust skills and tooling. This stuff now runs on QNX. Not only will this make our systems safer and more reliable, it will also save us so, so much time as safe Rust cannot cause memory corruptions or segfault and it almost never leaks memory. All of this with the same performance as C++.
I wouldn’t try to sell rust to the team/org using that particular claim. The so called modern c++ leaks memory as often as rust. It’s much better to focus on claims that will be very visible easy to verify, like prevention of memory corruption, data races and undefined behaviours when convincing others :)
I say “almost never leaks memory” because technically speaking, safe Rust does not guarantee freeing all the memory. In practice, however, memory leaks in Rust are extremely rare due to lifetime management at compile time. It pretty much never happens because the compiler will complain if you mismanage the lifetimes of your objects. You automatically do it right because the language deliberately makes it hard to do it wrong.
This is in stark contrast to C++, where it is indeed true that
std::unique_ptr(etc.) cleans up automatically, but the language does literally nothing to prevent you from just allocating memory willy-nilly and not freeing it.Saying that modern C++ leaks memory just as often as Rust is like saying that if you always brake carefully and in time, you travel just as safely as if you wore a seatbelt. Which might technically be true, but it does not reflect reality because humans make mistakes.
A very easy way to leak memory in Rust is to have a cyclical reference with an
Arcwithout having the other side as aWeak. This makes building classic Java style trees a bit cumbersome, if you need to traverse in both directions.A good structure is to just use flat vectors for your tree, but if you come from Java, cyclical reference counting is a quite common leak to make.
I don’t know what is your experience with both languages, but as far as I’m concerned allocating a pointer and losing track of it is not the typical leak that I had to deal with (more common in c++ but possible in safe rust). In fact I had to fix a leak caused by incorrect reference count in
Arcdue to bug inunsafepart usingMaybeUninitlast week 🙃In my experience, most of the time the reason for constantly increasing memory usage (both rust and c++) is some long lived set or map that someone forgot to remove entries from. Since such space leaks are much more common and are equally likely in both languages, I wouldn’t try to sell rust as leaks preventing language.
This is in big contrast to stuff like preventing use after free and other UB - I’m writing rust professionally for last 3 years and I haven’t yet had to deal with any memory corruption, or data race. Which were a recurring issues when I was working in c++ codebases previously.
Interesting. That is precisely the type of leak that I most commonly encounter in C++ and pretty much never in Rust.
I’m talking about leaks where you lose or drop the pointer/handle to the resource. Of course there’s always the “endlessly growing map” kind of leak. This kind of leak cannot be prevented by any language because the programmer deliberately grows the data structure, which is an entirely different class of leak which is way easier to detect because you still have a handle to the data structure.
I agree with you that the main benefit of Rust is the safety that comes from the absence of memory corruptions and data races. And yes these issues appear in pretty much every non-trivial C++ code base no matter how skilled the programmers are.
I wish QNX was still open-ish source. Or at least available without a crazy license. :-C
Has Ferrous Systems said if they plan to open source the future Ferrocene toolchain project?
The answer to my question appears to be “yes”: https://github.com/ferrocene
At least the spec and the actual compiler are here. I’m guessing there’s probably documentation that Ferrous Systems/AdaCore clients also probably get access to.
You got it about right. The current answer for the repository is currently “no”, though. The reason is more that it would make our work (which includes undisclosed ports to other operating systems, things that need legal agreements like regressions tests, etc.) much harder and we’re a team that needs to look after their resources. However, we upstream our patches to the compiler and LLVM, things like the documentation. We have other things around open source in the back of our head, but I’d like to speak when they are well-formed :).
If you are looking at
ferrocene/rust, that’s the repos we use for patching upstream, it’s just way easier to go public<>public and shows where the patches are coming from.Hey, thanks heaps for that explanation - I really appreciate it. It’s great you’re planning to upstream as much as possible and also maintaining your spec in the open, that’s fantastic.
I can also appreciate that you’re in awkward place between “Rust development culture” and “automotive/industrial embedded development culture” where these cultures may have very different attitudes to open source. I’ve seen enough NDA-encumbered forks of old LLVM versions and the like to understand some of what’s lurking in there. :)
Very excited to see where this project ends up!