4 ms·

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 an

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.

patrec 7y ago
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++.
- ummonk 7y ago
  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.
  - patrec 7y ago
    I think that's true. Also given the dominance of C in the unix eco system, it's a more important problem to solve.
- saghm 7y ago
  > 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.
jcranmer 7y ago
> 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/library/rust/shared/Cargo.toml https://dxr.mozilla.org/mozilla-central/source/toolkit/libra... to describe all of the Rust libraries you have in your project.
- eximius 7y ago
  ... 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.
  - jcranmer 7y ago
    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/0e3c3895dcb40b6a1c1cf8c427c01b5e 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.
- leshow 7y ago
  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.
- pcwalton 7y ago
  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.

patrec 7y ago

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

ummonk 7y ago
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.
- patrec 7y ago
  I think that's true. Also given the dominance of C in the unix eco system, it's a more important problem to solve.
saghm 7y ago
> 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.

jcranmer 7y ago

> 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/library/rust/shared/Cargo.toml https://dxr.mozilla.org/mozilla-central/source/toolkit/libra... to describe all of the Rust libraries you have in your project.

eximius 7y ago
... 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.
- jcranmer 7y ago
  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/0e3c3895dcb40b6a1c1cf8c427c01b5e 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.
leshow 7y ago
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.
pcwalton 7y ago
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.