Hacker News Reader

Comment by sureglymop | Hacker News Reader

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.

View on HN

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!

LMAO. Alright you made me laugh you got me there. My secret plot fam…

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++.

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.

> 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.

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.

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).

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.

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.

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.

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.

https://www.redox-os.org/

This is closer to an RTOS, but since we're also talking about embedded, we wrote 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.

> "Sure just wrap everything in "Unsafe"... So what is the point?"

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."

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.

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) and anecdotally, unsafe code was much less than 1% of the codebase.

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.

I'm also not a Rust programmer so I can't comment on whether people are overusing it, I was commenting on the suggestion that "if you're using unsafe{} in Rust what's the point in using Rust at all?" implying that it's basically C at that point, and it isn't - there's still a lot of safety checks the compiler does even in unsafe mode.

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.

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?

Reply on news.ycombinator.com