3 ms·

Even if you took the whole safety aspect away, why should I start a new project in Rust as opposed to C or C++? Rust has modern tooling, great IDE support and

Even if you took the whole safety aspect away, why should I start a new project in Rust as opposed to C or C++? Rust has modern tooling, great IDE support and a language server, nice dependency management, cargo and I could go on. Writing rust makes it imo much easier to structure your code and project as well. I just recently had to build a medium sized C project. The Makefile alone was at least 700 lines long. In my opinion I also just don't see younger people and newcomers putting up with that when there's a shiny new alternative. And if you want to sustain you have to attract new people and potential maintainers. Other than that, I agree that the rewriting is mostly not warranted. The thing is, it is about people and not really about code or programming language. If your entire team knows C well and will be able to maintain that project for years to come, it'd be weird to rewrite it all.

jdefr89 2y ago
Say you have to develop an embedded project. Try dealing with Rust and its dependency hell as everything you do requires a million different packages.. Or, develop me a driver that needs DMA.. How about a kernel allocator? Want to do that? Sure just wrap everything in "Unsafe"... So what is the point? Furthermore Rust programs link to libc ironically.
- kbolino 2y ago
  You're definitely not going to be linking to libc in a no_std environment, which is going to cover much (though not all) of embedded development. That will also remove some of the most bloated library dependencies from even being available to you in the first place, and of the rest, it will debloat a lot of them. Even if your embedded development is targeting a hosted platform with libstd available, whether you link libc will depend on whether you use libc. Thanks to its stable syscall ABI, you don't have to link anything on Linux. But most other similarly situated operating systems require you to link something, whether it be USER32.DLL/KERNEL32.DLL on Windows, libSystem*.dylib on macOS, or yes, libc*.so on (most of?) the BSDs and other UNIX systems. And when libc is not required by the platform, but you do need some of its functionality (either out of convenience or cross-platform compatibility), you can statically link it (including MSVCRT on Windows).
- dralley 2y ago
  All of that HAS been done in Rust. It's not that bad. It's actually quite good in many ways. #[no_std] is fairly unique to Rust.
  - jdefr89 2y ago
    Yes it has and can be done with rust. But usually by writing “unsafe” code so what the hell is the point if the majority of the code isn’t gonna have the Rust memory guarantees it would normally have? Furthermore, not all MCUs have a Rust compiler or tool chain to use. C is the defacto standard. Not saying it cannot be done, just that I am not sure it’s worth the extra effort and overhead.
    - dralley 2y ago
      Entire kernels have been written in Rust with less than 10% unsafe code. The entire line of argument that "the majority of code" needs to be unsafe in such contexts is BS. Especially when the "Rust culture" suggests building safe abstractions on top of unsafe building blocks, which tends to keep the unsafe code pretty well-contained to a small section of the codebase. There's plenty of Rust frameworks for microcontroller programming (embassy, etc.) that don't involve much if any unsafe Rust at all.
      - jdefr89 2y ago
        Can you link me to a viable/real world kernel rewritten in Rust? One that supports modern hardware? I am not talking about implementing a toy kernel here.
        Ar-Curunir 2y ago
        https://www.redox-os.org/ https://www.redox-os.org/
        steveklabnik 2y ago
        This is closer to an RTOS, but since we're also talking about embedded, we wrote https://hubris.oxide.computer/ https://hubris.oxide.computer/ for use in our products. Kernel is about 3% unsafe code last I checked, which was just a few months ago.
- jodrellblank 2y ago
  > "Sure just wrap everything in "Unsafe"... So what is the point?" https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html : "You can take five actions in unsafe Rust that you can’t in safe Rust .. it’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked .. by requiring these five unsafe operations to be inside blocks annotated with unsafe you’ll know that any errors related to memory safety must be within an unsafe block. Keep unsafe blocks small; you’ll be thankful later when you investigate memory bugs."
  - bluGill 2y ago
    You are confusing best practice for what is done all too often. Unsafe should be small blocks, but I've seen people put unsafe on everything even though it isn't needed thus making it hard to find where it is needed. I'm not a rust programmer, but I'm lead to believe that those people then do things that need unsafe - but a safe option not only exists but would have been easier to write.
    - School-Cotton 2y ago
      For very low-level stuff (e.g. embedded) you might need a lot of unsafe. For the vast majority of software it’s extremely rare. I worked full time for five years on a Rust project (https://github.com/MaterializeInc/materialize https://github.com/MaterializeInc/materialize) and anecdotally, unsafe code was much less than 1% of the codebase.
      - bluGill 2y ago
        I don't have direct experience, but from what I can gather between others, and my general embedded experience, unsafe in the worse case of embedded would still be just a small percentage of all code. (a device driver which would need unsafe to deal with hardware still has a lot of code that doesn't deal with hardware) There is some rust code out there that is more than 50% unsafe though.
    - 2y ago
- 0x457 2y ago
  I'm current working on an embedded project in rust. The most annoying part is when the project is shared with a non-embedded part, but otherwise it's a breeze to work on. Had no issues using DMA or anything else.
jujube3 2y ago
Read his comment. This guy literally writes exploits for C/C++ software. Of course he wants you to keep using memory-unsafe languages, otherwise his business dries up!
- jdefr89 2y ago
  LMAO. Alright you made me laugh you got me there. My secret plot fam…
lvass 2y ago
Clangd just works, and quite nicely, for me in Emacs, didn't even need to install any external package besides clang-tools from my distro's repository. I don't get this argument at all. The dependency management advantage is probably cool until you realize you can basically only trust distro maintainers to provide long term support for dependencies and crates makes it much harder for them, and makes programs less likely to remain secure in the long run. Who's going to fix a heap of Rust abandonware when an exploit is found in their transient dependencies?
quotemstr 2y ago
C++'s metaprogramming is still better. Rust needs specialization, const expressions, and a bunch of other things before it can be a full replacement for C++.
- School-Cotton 2y ago
  You’re right, but most people who are still using C++ over rust aren’t doing so because of better metaprogramming. It’s a relatively minor advantage, and on the other side, the advantages of Rust over C++ are massive.
bluGill 2y ago
> why should I start a new project You should not. Simple as that. Odds are very good there already is a project that does what you want and you should join or buy that. If you start a new project you have a lot of effort to be just as good as the previous one, and those projects are not standing still. Okay, maybe it makes sense to start a new game. However you should use an existing game engine not build your own. A few other things like that exist.

jdefr89 2y ago

Say you have to develop an embedded project. Try dealing with Rust and its dependency hell as everything you do requires a million different packages.. Or, develop me a driver that needs DMA.. How about a kernel allocator? Want to do that? Sure just wrap everything in "Unsafe"... So what is the point? Furthermore Rust programs link to libc ironically.

kbolino 2y ago
You're definitely not going to be linking to libc in a no_std environment, which is going to cover much (though not all) of embedded development. That will also remove some of the most bloated library dependencies from even being available to you in the first place, and of the rest, it will debloat a lot of them. Even if your embedded development is targeting a hosted platform with libstd available, whether you link libc will depend on whether you use libc. Thanks to its stable syscall ABI, you don't have to link anything on Linux. But most other similarly situated operating systems require you to link something, whether it be USER32.DLL/KERNEL32.DLL on Windows, libSystem*.dylib on macOS, or yes, libc*.so on (most of?) the BSDs and other UNIX systems. And when libc is not required by the platform, but you do need some of its functionality (either out of convenience or cross-platform compatibility), you can statically link it (including MSVCRT on Windows).
dralley 2y ago
All of that HAS been done in Rust. It's not that bad. It's actually quite good in many ways. #[no_std] is fairly unique to Rust.
- jdefr89 2y ago
  Yes it has and can be done with rust. But usually by writing “unsafe” code so what the hell is the point if the majority of the code isn’t gonna have the Rust memory guarantees it would normally have? Furthermore, not all MCUs have a Rust compiler or tool chain to use. C is the defacto standard. Not saying it cannot be done, just that I am not sure it’s worth the extra effort and overhead.
  - dralley 2y ago
    Entire kernels have been written in Rust with less than 10% unsafe code. The entire line of argument that "the majority of code" needs to be unsafe in such contexts is BS. Especially when the "Rust culture" suggests building safe abstractions on top of unsafe building blocks, which tends to keep the unsafe code pretty well-contained to a small section of the codebase. There's plenty of Rust frameworks for microcontroller programming (embassy, etc.) that don't involve much if any unsafe Rust at all.
    - jdefr89 2y ago
      Can you link me to a viable/real world kernel rewritten in Rust? One that supports modern hardware? I am not talking about implementing a toy kernel here.
      - Ar-Curunir 2y ago
        https://www.redox-os.org/ https://www.redox-os.org/
      - steveklabnik 2y ago
        This is closer to an RTOS, but since we're also talking about embedded, we wrote https://hubris.oxide.computer/ https://hubris.oxide.computer/ for use in our products. Kernel is about 3% unsafe code last I checked, which was just a few months ago.
jodrellblank 2y ago
> "Sure just wrap everything in "Unsafe"... So what is the point?" https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html : "You can take five actions in unsafe Rust that you can’t in safe Rust .. it’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked .. by requiring these five unsafe operations to be inside blocks annotated with unsafe you’ll know that any errors related to memory safety must be within an unsafe block. Keep unsafe blocks small; you’ll be thankful later when you investigate memory bugs."
- bluGill 2y ago
  You are confusing best practice for what is done all too often. Unsafe should be small blocks, but I've seen people put unsafe on everything even though it isn't needed thus making it hard to find where it is needed. I'm not a rust programmer, but I'm lead to believe that those people then do things that need unsafe - but a safe option not only exists but would have been easier to write.
  - School-Cotton 2y ago
    For very low-level stuff (e.g. embedded) you might need a lot of unsafe. For the vast majority of software it’s extremely rare. I worked full time for five years on a Rust project (https://github.com/MaterializeInc/materialize https://github.com/MaterializeInc/materialize) and anecdotally, unsafe code was much less than 1% of the codebase.
    - bluGill 2y ago
      I don't have direct experience, but from what I can gather between others, and my general embedded experience, unsafe in the worse case of embedded would still be just a small percentage of all code. (a device driver which would need unsafe to deal with hardware still has a lot of code that doesn't deal with hardware) There is some rust code out there that is more than 50% unsafe though.
  - 2y ago
0x457 2y ago
I'm current working on an embedded project in rust. The most annoying part is when the project is shared with a non-embedded part, but otherwise it's a breeze to work on. Had no issues using DMA or anything else.

jujube3 2y ago

Read his comment. This guy literally writes exploits for C/C++ software. Of course he wants you to keep using memory-unsafe languages, otherwise his business dries up!

jdefr89 2y ago
LMAO. Alright you made me laugh you got me there. My secret plot fam…

lvass 2y ago

Clangd just works, and quite nicely, for me in Emacs, didn't even need to install any external package besides clang-tools from my distro's repository. I don't get this argument at all. The dependency management advantage is probably cool until you realize you can basically only trust distro maintainers to provide long term support for dependencies and crates makes it much harder for them, and makes programs less likely to remain secure in the long run. Who's going to fix a heap of Rust abandonware when an exploit is found in their transient dependencies?

quotemstr 2y ago

C++'s metaprogramming is still better. Rust needs specialization, const expressions, and a bunch of other things before it can be a full replacement for C++.

School-Cotton 2y ago
You’re right, but most people who are still using C++ over rust aren’t doing so because of better metaprogramming. It’s a relatively minor advantage, and on the other side, the advantages of Rust over C++ are massive.

bluGill 2y ago

> why should I start a new project You should not. Simple as that. Odds are very good there already is a project that does what you want and you should join or buy that. If you start a new project you have a lot of effort to be just as good as the previous one, and those projects are not standing still. Okay, maybe it makes sense to start a new game. However you should use an existing game engine not build your own. A few other things like that exist.