4 ms·

Looking at the c code and comparing it with standard c++ (raii, smart pointers).. why not use c++? Sure rust has additional safety features that alone is worth

Looking at the c code and comparing it with standard c++ (raii, smart pointers).. why not use c++? Sure rust has additional safety features that alone is worth it but they were mentioning ref counting,locking , bounds checking,error handling .. most of that is doable with pedestrian c++

nercury 3y ago
First and foremost, algebraic data types, specifically, proper sum types, called "enums" in rust. Think safe C unions or sane C++ variant. Everything is built on them, they help to encode various states and ensure they aren't misused. Second, moves by default. They make building wrappers that depend on creation and destruction of a value much easier. They can track various things: memory usage, threads, temporary pointers, or whatever else. Unlike unique_ptr, they are on stack and part of the type system.
ansible 3y ago
Linus Torvalds famously does not like and will not allow the use of C++ in the Linux kernel. Also, Rust explicitly puts safety first, and C++ cannot give the same guarantees for normal code. The uses of `unsafe` in Rust should be relatively uncommon and deserve extra scrutiny.
- dig1 3y ago
  > C++ cannot give the same guarantees for normal code Can you give me example of a normal C++ code where compiler and/or language will not guarantee safety? Let's put aside UBs, because they are everything but normal code.
  - Tyr42 3y ago
    Allows you to modify containers while iterating.
  - nercury 3y ago
    I would avoid saying that it's "Rust" that "gives guarantees". It paints Rust as this magical thing that will solve anything. My preferred explanation is that Rust provides better tools to build wrappers that can't be misused. The idea is to solve hard problem once, and reap the benefits many times. But it all depends on wrapper author. In that regard, it is perfectly possible to write horrible Rust code.
    - vitiral 3y ago
      > I would avoid saying that it's "Rust" that "gives guarantees". Why would you avoid saying that? Rust does give guarantees: about memory safety and concurrency primarily, but also regarding the lack of undefined behavior. > It paints Rust as this magical thing that will solve anything. It does not, the above are not magical they are just challenging problems (although at some point they may have been deemed impossible problems and hence magical, I don't know) > My preferred explanation is that Rust provides better tools to build wrappers that can't be misused. "wrappers that can't be misused" sounds a LOT like it "gives guarantees".
      - nercury 3y ago
        The biggest wrapper that gives guarantees is the standard library, and usually, when people say that Rust does not do something, they have standard library in mind. For example, standard library made the choice to hide panics in out-of-memory situations. That does not mean you can't write your own version of relevant structures to gain different guarantees. I like to highlight the actual strengths of Rust (as a tool) instead of particular implementation details, especially when we are talking about situation (kernel) where Rust is used without its standard library.
        sophacles 3y ago
        Rust the language gives these guarantees without the use of the unsafe keyword: * you will not be able to compile undefined behavior * you will not be able to create a data race * a shared reference is read-only * you cannot write past the end of an array There are others, but those are pretty big ones that both guarantees and part of the language itself, independent of stdlib.
  - moregrist 3y ago
    Please define “normal”. Normal C++ for me runs the gamut of looking a lot like C to be a template metaprogramming monstrosity. Almost all C++ code interacts with bare pointers at some point. And that’s just one of the places where you get into issues with safety. You can also run into problems with iterators being invalidated: your iterator into a std::vector is no longer valid after a call to push_back(). Anything that stores a reference and can exist after the lifetime of the object, really. Lambdas are a problem here. But so are instances with reference members. C++ is littered with these things.
    - msla 3y ago
      > Almost all C++ code interacts with bare pointers at some point. This is a device driver. If it has to talk to memory-mapped hardware, that's a raw pointer, inherently, inevitably. Other things are language issues, and can be solved by changing languages, but raw pointers are inherent in the task.
      - cesarb 3y ago
        > This is a device driver. If it has to talk to memory-mapped hardware This is an IPC "device driver". It does not talk to any hardware, it's used to pass messages between processes.
      - Narishma 3y ago
        > This is a device driver. It's not, it's an IPC subsystem. It doesn't talk to any hardware.
  - AgentME 3y ago
    Undefined behavior is absolutely easy to trigger in normal C++ code, and being able to prevent it is a massive safety benefit. Ignoring UB while talking about safety is like ignoring car crashes when judging whether seat belts give any benefit. An easy way to trigger undefined behavior in C++ is by using a pointer after the thing it's pointing to has been freed. Doing this in a process that takes any user input can easily create a vulnerability that allows an attacker to inject code into the process. There are many ways to accidentally do this while thinking you're safe. A pointer to an item inside a data structure like a vector or hash table is dangerous if you use it after some items may have been inserted into the data structure, because inserts can cause the data structure to reallocate and expand its backing memory. This mistake can easily go unnoticed for a long time because only a small fraction of inserts will cause that. This mistake isn't possible to make in safe Rust.
  - dthul 3y ago
    Defining "normal" code as "not having UB" is quite disingenuous though, isn't it? Iterating over a vector while adding elements for example looks normal, but isn't generally safe, unless you know to pre-allocate enough memory.
- ninkendo 3y ago
  It’s actually sort of interesting why Linus has basically closed the door on C++ ever getting into the kernel, while Rust seems to have gotten the green light. If you look at Linus’s initial reasoning [0] (which was from a long time ago, nearly 20 years now, way before C++11), it was because the abstractions it offered/encouraged could make it hard to reason about what’s really happening, which may be bad for kernel code, and that allowing C++ would open the floodgates for C++ programmers to contribute, and Linus famously hated C++ programmers. Rust-in-the-kernel came up many years later, and IMO if Linus was really honest with himself he’d either (1) not allow rust for essentially the same reasons he disallowed C++, or (2) admit his views have evolved, and say that C++ should be allowed on the same tentative basis that Rust is. I get that rust offers safety advantages that C++ doesn’t, but I don’t think that’s the complete picture… modern C++ offers so many of the same advantages (although obviously not all) that if we’re really being honest with ourselves, it would seem to be unfair that Rust is let in while C++ is not. Both of them are enormous steps up in safety over C. [0] https://harmful.cat-v.org/software/c++/linus https://harmful.cat-v.org/software/c++/linus
  - hypeatei 3y ago
    > Both of them are enormous steps up in safety over C. I would argue one (Rust) is, but not C++. Rust is more "batteries included" and doesn't require specific compiler flags or complicated tooling, it just works and gives you guarantees out of the box. C++ seems to allow escape hatches by default while Rust requires you to call that out via `unsafe`.
  - insanitybit 3y ago
    > not allow rust for essentially the same reasons he disallowed C++, Unless what he disliked was the inheritance/OOP stuff in C++, which isn't an issue in Rust.
    - pjmlp 3y ago
      Rust has its own flavour of OOP, only data inheritance isn't part of the picture. Interfaces/traits, dynamic dispatch, static dispatch, encapsulation, polymorphism, traits inheritance, is all there. Additionally macro system as powerful as Common Lisp, which allows to do stuff that would make Linus blowup on the spot.
TwentyPosts 3y ago
To flip the question on its head, why bother with C++ when you can use Rust?
- jhoechtl 3y ago
  30+ years of experience and time to ripen?
  - deleted 3y ago
    [deleted]
  - baq 3y ago
    exactly the reasons to use rust, actually
  - wiseowise 3y ago
    > time to ripen You mean time to rot?
- bluGill 3y ago
  C++ with raii was an option 25 years ago. Today rust is the hot new in thing, but we waited a long time. There are rough edges in C too.
  - vitiral 3y ago
    If it's just about number of years then Rust 1.0 was in May 2015, so more than 8 years. Does a "thing" need to be around for a decade+ to no longer be "hot" or "new"?
  - AlotOfReading 3y ago
    C++ with RAII doesn't make the language safe, it makes it less unsafe. Instead, we have 25 years of incremental language additions without meaningfully deprecating things. The officially sanctioned way to write memory-safe code in C++ is a non-existent set of compiler warnings that error when you use 80% of the language (profiles). To quote Stroustrup and P2410 [0]: "Experience shows that this [memory safety] cannot be done without static analysis and run-time support. Furthermore, for fundamental reasons this cannot done even with such support if arbitrary legal language constructs are accepted while conventional good performance must be maintained." [0] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2410r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p24...
gemstones 3y ago
Google is making the smart bet that there will be juniors who will learn Rust and can contribute to Binder 10 years from now, while their experienced C++ devs will only shrink and need to be reserved for more critical projects.

nercury 3y ago

First and foremost, algebraic data types, specifically, proper sum types, called "enums" in rust. Think safe C unions or sane C++ variant. Everything is built on them, they help to encode various states and ensure they aren't misused. Second, moves by default. They make building wrappers that depend on creation and destruction of a value much easier. They can track various things: memory usage, threads, temporary pointers, or whatever else. Unlike unique_ptr, they are on stack and part of the type system.

ansible 3y ago

Linus Torvalds famously does not like and will not allow the use of C++ in the Linux kernel. Also, Rust explicitly puts safety first, and C++ cannot give the same guarantees for normal code. The uses of `unsafe` in Rust should be relatively uncommon and deserve extra scrutiny.

dig1 3y ago
> C++ cannot give the same guarantees for normal code Can you give me example of a normal C++ code where compiler and/or language will not guarantee safety? Let's put aside UBs, because they are everything but normal code.
- Tyr42 3y ago
  Allows you to modify containers while iterating.
- nercury 3y ago
  I would avoid saying that it's "Rust" that "gives guarantees". It paints Rust as this magical thing that will solve anything. My preferred explanation is that Rust provides better tools to build wrappers that can't be misused. The idea is to solve hard problem once, and reap the benefits many times. But it all depends on wrapper author. In that regard, it is perfectly possible to write horrible Rust code.
  - vitiral 3y ago
    > I would avoid saying that it's "Rust" that "gives guarantees". Why would you avoid saying that? Rust does give guarantees: about memory safety and concurrency primarily, but also regarding the lack of undefined behavior. > It paints Rust as this magical thing that will solve anything. It does not, the above are not magical they are just challenging problems (although at some point they may have been deemed impossible problems and hence magical, I don't know) > My preferred explanation is that Rust provides better tools to build wrappers that can't be misused. "wrappers that can't be misused" sounds a LOT like it "gives guarantees".
    - nercury 3y ago
      The biggest wrapper that gives guarantees is the standard library, and usually, when people say that Rust does not do something, they have standard library in mind. For example, standard library made the choice to hide panics in out-of-memory situations. That does not mean you can't write your own version of relevant structures to gain different guarantees. I like to highlight the actual strengths of Rust (as a tool) instead of particular implementation details, especially when we are talking about situation (kernel) where Rust is used without its standard library.
      - sophacles 3y ago
        Rust the language gives these guarantees without the use of the unsafe keyword: * you will not be able to compile undefined behavior * you will not be able to create a data race * a shared reference is read-only * you cannot write past the end of an array There are others, but those are pretty big ones that both guarantees and part of the language itself, independent of stdlib.
- moregrist 3y ago
  Please define “normal”. Normal C++ for me runs the gamut of looking a lot like C to be a template metaprogramming monstrosity. Almost all C++ code interacts with bare pointers at some point. And that’s just one of the places where you get into issues with safety. You can also run into problems with iterators being invalidated: your iterator into a std::vector is no longer valid after a call to push_back(). Anything that stores a reference and can exist after the lifetime of the object, really. Lambdas are a problem here. But so are instances with reference members. C++ is littered with these things.
  - msla 3y ago
    > Almost all C++ code interacts with bare pointers at some point. This is a device driver. If it has to talk to memory-mapped hardware, that's a raw pointer, inherently, inevitably. Other things are language issues, and can be solved by changing languages, but raw pointers are inherent in the task.
    - cesarb 3y ago
      > This is a device driver. If it has to talk to memory-mapped hardware This is an IPC "device driver". It does not talk to any hardware, it's used to pass messages between processes.
    - Narishma 3y ago
      > This is a device driver. It's not, it's an IPC subsystem. It doesn't talk to any hardware.
- AgentME 3y ago
  Undefined behavior is absolutely easy to trigger in normal C++ code, and being able to prevent it is a massive safety benefit. Ignoring UB while talking about safety is like ignoring car crashes when judging whether seat belts give any benefit. An easy way to trigger undefined behavior in C++ is by using a pointer after the thing it's pointing to has been freed. Doing this in a process that takes any user input can easily create a vulnerability that allows an attacker to inject code into the process. There are many ways to accidentally do this while thinking you're safe. A pointer to an item inside a data structure like a vector or hash table is dangerous if you use it after some items may have been inserted into the data structure, because inserts can cause the data structure to reallocate and expand its backing memory. This mistake can easily go unnoticed for a long time because only a small fraction of inserts will cause that. This mistake isn't possible to make in safe Rust.
- dthul 3y ago
  Defining "normal" code as "not having UB" is quite disingenuous though, isn't it? Iterating over a vector while adding elements for example looks normal, but isn't generally safe, unless you know to pre-allocate enough memory.
ninkendo 3y ago
It’s actually sort of interesting why Linus has basically closed the door on C++ ever getting into the kernel, while Rust seems to have gotten the green light. If you look at Linus’s initial reasoning [0] (which was from a long time ago, nearly 20 years now, way before C++11), it was because the abstractions it offered/encouraged could make it hard to reason about what’s really happening, which may be bad for kernel code, and that allowing C++ would open the floodgates for C++ programmers to contribute, and Linus famously hated C++ programmers. Rust-in-the-kernel came up many years later, and IMO if Linus was really honest with himself he’d either (1) not allow rust for essentially the same reasons he disallowed C++, or (2) admit his views have evolved, and say that C++ should be allowed on the same tentative basis that Rust is. I get that rust offers safety advantages that C++ doesn’t, but I don’t think that’s the complete picture… modern C++ offers so many of the same advantages (although obviously not all) that if we’re really being honest with ourselves, it would seem to be unfair that Rust is let in while C++ is not. Both of them are enormous steps up in safety over C. [0] https://harmful.cat-v.org/software/c++/linus https://harmful.cat-v.org/software/c++/linus
- hypeatei 3y ago
  > Both of them are enormous steps up in safety over C. I would argue one (Rust) is, but not C++. Rust is more "batteries included" and doesn't require specific compiler flags or complicated tooling, it just works and gives you guarantees out of the box. C++ seems to allow escape hatches by default while Rust requires you to call that out via `unsafe`.
- insanitybit 3y ago
  > not allow rust for essentially the same reasons he disallowed C++, Unless what he disliked was the inheritance/OOP stuff in C++, which isn't an issue in Rust.
  - pjmlp 3y ago
    Rust has its own flavour of OOP, only data inheritance isn't part of the picture. Interfaces/traits, dynamic dispatch, static dispatch, encapsulation, polymorphism, traits inheritance, is all there. Additionally macro system as powerful as Common Lisp, which allows to do stuff that would make Linus blowup on the spot.

TwentyPosts 3y ago

To flip the question on its head, why bother with C++ when you can use Rust?

jhoechtl 3y ago
30+ years of experience and time to ripen?
- deleted 3y ago
  [deleted]
- baq 3y ago
  exactly the reasons to use rust, actually
- wiseowise 3y ago
  > time to ripen You mean time to rot?
bluGill 3y ago
C++ with raii was an option 25 years ago. Today rust is the hot new in thing, but we waited a long time. There are rough edges in C too.
- vitiral 3y ago
  If it's just about number of years then Rust 1.0 was in May 2015, so more than 8 years. Does a "thing" need to be around for a decade+ to no longer be "hot" or "new"?
- AlotOfReading 3y ago
  C++ with RAII doesn't make the language safe, it makes it less unsafe. Instead, we have 25 years of incremental language additions without meaningfully deprecating things. The officially sanctioned way to write memory-safe code in C++ is a non-existent set of compiler warnings that error when you use 80% of the language (profiles). To quote Stroustrup and P2410 [0]: "Experience shows that this [memory safety] cannot be done without static analysis and run-time support. Furthermore, for fundamental reasons this cannot done even with such support if arbitrary legal language constructs are accepted while conventional good performance must be maintained." [0] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2410r0.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p24...

gemstones 3y ago

Google is making the smart bet that there will be juniors who will learn Rust and can contribute to Binder 10 years from now, while their experienced C++ devs will only shrink and need to be reserved for more critical projects.