Hacker News Reader

Comment by patrec | Hacker News Reader

What features does Rust have that C++ lacks that allows it to be used as a C replacement when C++ can't be?

Memory safety?

C++ has lots of bells and whistles, some of which Rust doesn't have (classes, to name one), but those aren't necessarily more important bells and whistles.

Also, the Rust infrastructure is light-years ahead of linking in libraries in C/C++. Compile times are higher, but not horribly so.

> Also, the Rust infrastructure is light-years ahead of linking in libraries in C/C++. Compile times are higher, but not horribly so.

Sorry, but you've got this backwards. From a user's perspective, cargo seems like a much nicer build system than the more-or-less manual build systems of make et al. But that's because cargo is opinionated and inflexible: it really wants to be the primary driver of the build system, and it also doesn't quite support all of the things you can do with custom linking.

As a result, when you have large projects composed of multiple libraries, your choices are either to drive rustc manually and skip cargo altogether, or to create a single macro crate for cargo to link all the rust code as a sublibrary for linking into your main project code. You end up with something like this: https://dxr.mozilla.org/mozilla-central/source/toolkit/libra... to describe all of the Rust libraries you have in your project.

What you're saying is essentially that Cargo follows the principle of "easy things should be easy; hard things should be possible". CMake, Autotools, Make, etc. do not follow this principle; hard things are possible, but easy things are not easy. This might look like inflexibility, but I don't really see that. Cargo does let you do hard things; it's just that it has a "normal" workflow as well, which makes the simple case simple.

... is that bad?

Seems different. But it doesn't seem bad.

Granted, I've not worked on a project of that size, but it seems to me that if it works for 'normal' sized projects quite well and works as well as anything else for large projects (as in, nothing works perfectly for large projects, they all need tweaking), then it is ahead of the alternatives.

What it shows is that Rust's aggressive approach to static linking means that it doesn't slot into build systems the same way that C/C++ code does. This has benefits for smaller projects, but it probably discourages use in larger projects.

I don't know what all of the trade-offs are, so I don't know where the current situation sits in this space. https://gist.github.com/rylev/0e3c3895dcb40b6a1c1cf8c427c01b... is the minutes of a session between the scary-custom-build-system people discussing (among other things) the pain points of cargo with their build systems.

That only happens in an extremely small amount of cases. Almost all of the time cargo does nothing but make your life easier.

No tool is perfect, but the team seems pretty dedicated to improving things.

Sure, but memory safety is irrelevant when considering C++ as a C replacement (C++'s memory safety, terrible as it is, is not worse than C's). I'm purely curious as to why you'd be able to write something in either a) C b) Rust but not c) C++.

You are reading that backwards. The comment said that Rust is better positioned as a C replacement than it is as a C++ replacement. It said nothing about C being able to do things C++ can’t.

I think that's true. Also given the dominance of C in the unix eco system, it's a more important problem to solve.

> Sure, but memory safety is irrelevant when considering C++ as a C replacement (C++'s memory safety, terrible as it is, is not worse than C's).

Wouldn't it be fair to say that reducing memory unsafety as much as possible without hurting performance is a good goal to have when making a replacement for C? Assuming that's the case, it's relevant that C++ doesn't eliminate it as much as Rust when comparing the two languages as C replacements.

(1) Memory safety guarantees through the ownership model, a clear delineation of unsafe code that doesn't follow it. Also, no UD.

(2) Both Rust and C++ can be used to write most / all of the code that can be written in C, at a zero runtime cost. Their difference is in ergonomics, safety features, ecosystem maturity, etc.

Arguably, the point is precisely that Rust lacks features that C++ has which make C++ not as good as it could be at replacing C.

Rust has put more effort than C++ into figuring out how much of the standard library can be used in "freestanding environments" (to borrow the C terminology). C++ without exceptions, RTTI, and the standard library is already a pretty effective C replacement.

The other "feature" that C++ has in this space is that it has a bad reputation as far as the C stalwarts are concerned, whereas Rust has not gained that reputation.

C++ isn't very homogenous in the features that people use. I was speaking more to the fact that one can use Rust in situations where C traditionally dominates. OS's, embedded development. It's memory safety model allows you to section off unsafe code and craft safe interfaces while still operating on the bare metal. Like sibling comments mentioned, no_std is pretty great too.

I don't think the parent was saying you can use Rust anywhere you can't use C++. I think they were saying, Rust is not only a good C++ alternative, but also a good C alternative.

Assuming GP's post was not edited, I don't see where it implies that Rust can be used as a C replacement where C++ can't.

This is a good question, and it's a shame that none of the responses so far answer it.

The answer to that specific question is borrow checker (i.e. memory safety) and much better type system.

Those things can't be essential in a C replacement, because C doesn't have them. The statement implies that there are things C can do that C++ can't but Rust can.

Reply on news.ycombinator.com