3 ms·

I'm somewhat puzzled - the obvious answer is that you don't have to use them. Rust by itself is no less feature complete than C. Anything you can write in C wit

by troad 3y ago

I'm somewhat puzzled - the obvious answer is that you don't have to use them. Rust by itself is no less feature complete than C. Anything you can write in C without dependencies, you can write in Rust without dependencies too. Of course, dependency-reliance falls on a spectrum for any individual programmer. On the one hand you have script kiddies with 400 npm dependencies gathered from arcane Discord channels - on the other you have old bearded wizards who don't understand why you'd need printf() when you can just mov rax 1; syscall. I find Rust is not strongly opinionated about this. You can just as easily eschew dependencies as use them. There's usually a good array of options available, or you could always FFI to a C lib directly if you need to.

palata 3y ago
> I'm somewhat puzzled Because you find it fine to say that "people dramatically overestimate the correctness of their [C/C++] code", but not fine to say that "people tend to depend on too many third-parties that they never question"?
- iknowstuff 3y ago
  We have solid data on how much Rust improves safety, while “too many” dependencies seems rather arbitrary. They tend to be high quality and better vetted/tested than bespoke code or copy-pasted hpp headers
  - palata 3y ago
    > They tend to be high quality and better vetted/tested I thought anyone could publish rust packages, just like for PyPi? Are the packages audited before they are published in Rust? > “too many” dependencies seems rather arbitrary I would say that you have "too many" dependencies when you don't have control over them, e.g. because you can't afford auditing them or maintaining them. I have seen multiple Rust projects that I would rather rewrite myself than audit their tens (hundreds) of dependencies. That's "too many".
    - troad 3y ago
      > I thought anyone could publish rust packages, just like for PyPi? Are the packages audited before they are published in Rust? Who prevents nasty C/C++ packages from being published? To my knowledge, anyone can just publish a C/C++ library. > I would say that you have "too many" dependencies when you don't have control over them, e.g. because you can't afford auditing them or maintaining them. I have seen multiple Rust projects that I would rather rewrite myself than audit their tens (hundreds) of dependencies. That's "too many". Then don't use them? Your concerns appear to boil down to 'bad software exists'. Which... yeah. It does. Not sure what you want us to say. It's an intrinsic characteristic of open source / free software, and it's not like C/C++ is somehow under-represented (or Rust over-represented) in dodgy software. There's plenty of closed ecosystems you can stick to if you don't trust yourself not to use dodgy dependencies (though I think this is a very strange concern to have).
      - palata 3y ago
        > Who prevents nasty C/C++ packages from being published? To my knowledge, anyone can just publish a C/C++ library. Distros have system package managers that are checked by the distro maintainers. And by definition you trust the maintainers of your distro. Somehow it feels like Rust does not go really well with distros (because it pushes for static linking). > Your concerns appear to boil down to 'bad software exists'. I was reacting to someone generalizing on C/C++ code, saying that "people dramatically overestimate it". I feel like it's nice to have some memory safety brought by Rust, but I find it a bit hypocritical to criticize the security of C/C++ code if Rust projects tend to statically link random code from hundreds of dependencies nobody ever reads. Because that's a big security issue IMO. Sure, you can do it right with Rust. But you can also write good code with C/C++.
        troad 3y ago
        > Distros have system package managers that are checked by the distro maintainers. And by definition you trust the maintainers of your distro. You're comparing apples to oranges. Most C/C++ software in business use isn't pulling its dependencies from distro PMs, it's pulling them from some monstrous dark web of Visual Studio projects and opaque git repos. And on the other hand, Rust software that's distributed in distro PMs uses distro dependencies like any other package. Equally, as you note, the reverse exists. None of this tells us very much about Rust or C/C++ as languages. > Rust projects tend to statically link random code from hundreds of dependencies nobody ever reads 'Tend to' is doing a lot of heavy lifting in that sentence, and doesn't seem to be based on very much more than 'I saw it a few times'. Well, I've seen my share of nightmarish C++ dependency trees. Is that a good argument against C++? Not really. You're picking up on real issues - unnecessary and untrusted dependencies - except you're then erroneously drawing some imagined line in the sand where Rust bad and C/C++ good, which is where a rational argument seems to collapse into vibes. On the whole, there's a lot more C++ projects out there guilty of this than Rust projects. > Sure, you can do it right with Rust. But you can also write good code with C/C++. You can hammer a nail with a broom, but that doesn't make it the best tool for the job. The safety advantages of Rust can't just be hand-waved away. C is a fine programming language when safety is less of an issue. If you're writing a Nintendo emulator, sure, C, why not. If you're writing business logic that handles health data, maybe not.
- troad 3y ago
  Huh? Now I'm quite puzzled. I find both fine to say. I think I make it pretty clear in my comment that dependency use is a per-programmer issue. If you come to Rust with an unquenchable dependency-lust, then yeah, you'll wind up with a Cargo file that looks like the Chicago phonebook. But - here's the kicker - you can do that with C or C++ too! There's really nothing about Rust that requires or recommends this, is my point. Rust is a generally safer language than C, this much is fairly well established. That alone is an intrinsic advantage. I'm the sort of dev to inline handwritten assembly for a performance boost, so I feel very warmly towards C (which is just assembly in a wig), but for those things where correctness and safety is more important, Rust is simply the better tool.

by troad 3y ago

palata 3y ago

> I'm somewhat puzzled Because you find it fine to say that "people dramatically overestimate the correctness of their [C/C++] code", but not fine to say that "people tend to depend on too many third-parties that they never question"?

iknowstuff 3y ago
We have solid data on how much Rust improves safety, while “too many” dependencies seems rather arbitrary. They tend to be high quality and better vetted/tested than bespoke code or copy-pasted hpp headers
- palata 3y ago
  > They tend to be high quality and better vetted/tested I thought anyone could publish rust packages, just like for PyPi? Are the packages audited before they are published in Rust? > “too many” dependencies seems rather arbitrary I would say that you have "too many" dependencies when you don't have control over them, e.g. because you can't afford auditing them or maintaining them. I have seen multiple Rust projects that I would rather rewrite myself than audit their tens (hundreds) of dependencies. That's "too many".
  - troad 3y ago
    > I thought anyone could publish rust packages, just like for PyPi? Are the packages audited before they are published in Rust? Who prevents nasty C/C++ packages from being published? To my knowledge, anyone can just publish a C/C++ library. > I would say that you have "too many" dependencies when you don't have control over them, e.g. because you can't afford auditing them or maintaining them. I have seen multiple Rust projects that I would rather rewrite myself than audit their tens (hundreds) of dependencies. That's "too many". Then don't use them? Your concerns appear to boil down to 'bad software exists'. Which... yeah. It does. Not sure what you want us to say. It's an intrinsic characteristic of open source / free software, and it's not like C/C++ is somehow under-represented (or Rust over-represented) in dodgy software. There's plenty of closed ecosystems you can stick to if you don't trust yourself not to use dodgy dependencies (though I think this is a very strange concern to have).
    - palata 3y ago
      > Who prevents nasty C/C++ packages from being published? To my knowledge, anyone can just publish a C/C++ library. Distros have system package managers that are checked by the distro maintainers. And by definition you trust the maintainers of your distro. Somehow it feels like Rust does not go really well with distros (because it pushes for static linking). > Your concerns appear to boil down to 'bad software exists'. I was reacting to someone generalizing on C/C++ code, saying that "people dramatically overestimate it". I feel like it's nice to have some memory safety brought by Rust, but I find it a bit hypocritical to criticize the security of C/C++ code if Rust projects tend to statically link random code from hundreds of dependencies nobody ever reads. Because that's a big security issue IMO. Sure, you can do it right with Rust. But you can also write good code with C/C++.
      - troad 3y ago
        > Distros have system package managers that are checked by the distro maintainers. And by definition you trust the maintainers of your distro. You're comparing apples to oranges. Most C/C++ software in business use isn't pulling its dependencies from distro PMs, it's pulling them from some monstrous dark web of Visual Studio projects and opaque git repos. And on the other hand, Rust software that's distributed in distro PMs uses distro dependencies like any other package. Equally, as you note, the reverse exists. None of this tells us very much about Rust or C/C++ as languages. > Rust projects tend to statically link random code from hundreds of dependencies nobody ever reads 'Tend to' is doing a lot of heavy lifting in that sentence, and doesn't seem to be based on very much more than 'I saw it a few times'. Well, I've seen my share of nightmarish C++ dependency trees. Is that a good argument against C++? Not really. You're picking up on real issues - unnecessary and untrusted dependencies - except you're then erroneously drawing some imagined line in the sand where Rust bad and C/C++ good, which is where a rational argument seems to collapse into vibes. On the whole, there's a lot more C++ projects out there guilty of this than Rust projects. > Sure, you can do it right with Rust. But you can also write good code with C/C++. You can hammer a nail with a broom, but that doesn't make it the best tool for the job. The safety advantages of Rust can't just be hand-waved away. C is a fine programming language when safety is less of an issue. If you're writing a Nintendo emulator, sure, C, why not. If you're writing business logic that handles health data, maybe not.
troad 3y ago
Huh? Now I'm quite puzzled. I find both fine to say. I think I make it pretty clear in my comment that dependency use is a per-programmer issue. If you come to Rust with an unquenchable dependency-lust, then yeah, you'll wind up with a Cargo file that looks like the Chicago phonebook. But - here's the kicker - you can do that with C or C++ too! There's really nothing about Rust that requires or recommends this, is my point. Rust is a generally safer language than C, this much is fairly well established. That alone is an intrinsic advantage. I'm the sort of dev to inline handwritten assembly for a performance boost, so I feel very warmly towards C (which is just assembly in a wig), but for those things where correctness and safety is more important, Rust is simply the better tool.