4 ms·

"unfairly"? A lot of issues are obvious deficiencies of Rust, including immaturity of the ecosystem, integration issues, complexity, monomorphization bloat, su

• IshKebab 2y ago
  Yes. I was thinking of this: > If you do an experiment and say "C++" anywhere on the Internet, in a minute someone will chime in and educate you about the existence of Rust. > I know examples when engineers rewrite code from Rust in Rust if they like to rewrite everything in Rust. > our engineers become too nauseous from Rust poisoning > So now they [Rust devs] can write something other than new versions of old terminal applications. > someone shows PRQL, everyone else thinks "What a wonderful idea, and, also, Rust" and gives this project a star on GitHub. This is, by the way, how most of Rust projects get their stars on GitHub. It doesn't look like someone wants to use this language, but what we want is to ride the hype. > we started to understand that it would be hard to get rid of Rust, and we could tolerate it. It's a very shitty attitude and not even accurate. You see this attitude from old C/C++ devs quite a lot, it's just very weird that he has that attitude and then also seems to be simultaneously quite keen to use Rust. Very weird! Anyway those are just the non-technical things. On the technical side: > Fully offline builds They solved it by vendoring but this is the obvious solution and also applies to C++. > Segfault in Rust They tried to do a null-terminated read of a string that wasn't null-terminated. Nothing to do with Rust. That would be an error in C++ too. In fact this is a strong argument for Rust. > Panic C/C++ code aborts. Or more commonly it crashes in a very difficult to debug way. I'll take panics any day. > Sanitizers require nightly Ok fair enough but this seems relatively minor. > Rust's OpenSSL links with the system library by default and you have to set an environment variable to statically link it. They set the environment variable. Frankly this is a million times easier than doing the same thing in C++. I'll stop there, but overall it seems like a lot of "this is a problem we had with Rust" where it should really be more like "this is something we had to do when using C++ with Rust". Weird vibe anyway.
  • uecker 2y ago
    If I try to read between the lines, I think the vibe comes from feeling / being pressured to use Rust without really seeing the point and it causing frustration in this context. I think your vibe is more weird. If people have issues with Rust, it is a "shitty attitude". While, of course, C/C++ just objectively suck, right?
    • simonask 2y ago
      I think the comment you responded to gives pretty clear reasons why the take is weird or a "shitty attitude". Competent C++ developers are the first to admit that C++ objectively sucks. It's a bad language, but that doesn't mean there aren't good reasons to use it. Claiming that C++ is great is a weird hill to die on.
• AlotOfReading 2y ago
  > The main issue with Rust is that is has been oversold as a panacea for safety using exaggerated arguments. I know you know this, but Rust does provide essentially complete memory and lifetime safety if you stay within the bounds of safe. Standard C/C++ tooling has no way to even reliably detect memory safety violations, let alone fix them. It's trivial to write buffer overflows that escape ASAN, and missing a single violation invalidates the semantic meaning of the entire program (particularly in C++), which means virtually all nontrivial programs in C/C++ have UB somewhere (a point we disagree on). Safe rust doesn't guarantee all the other possible definitions of safety, but neither does any other mainstream language. I don't think it serves any useful purpose to complain that the rust folks have oversold their safety arguments by "only" eliminating the biggest cause of safety issues. Stroustrup harps on this a lot and it comes across as very disingenuous given the state of C++.
  • uecker 2y ago
    Your comment is a perfect example for those exaggerated claims.
    • AlotOfReading 2y ago
      Which claims do you think are exaggerated?
      • uecker 2y ago
        Let's start with this "... Rust does provide essentially complete memory and lifetime safety if you stay within the bounds of safe." Technically true, except for the fine print. In many scenarios you have to use "unsafe", e.g. to get equal performance to C in something as trivial as a matrix transpose or when interfacing to other code (cf. this article) Let's compare this to "It's trivial to write buffer overflows that escape ASAN,". The question is how difficult it is avoid writing such overflows. But by turning this around, you already made a biased and misleading statement. Or "and missing a single violation invalidates the semantic meaning of the entire program (particularly in C++)," again technically true, but a meaningless talking point. The only practical question is whether a violation leads to exploitable bug and and how difficult / costly it is to exploit. This "no semantic meaning" comment completely disregards the reality of mitigation which often are very effective. Continuing with "which means virtually all nontrivial programs in C/C++ have UB somewhere (a point we disagree on)." I actually agree with this, but most UB is irrelevant and easily mitigated, e.g. signed overflow is not an issue at all because you just tell your compiler to turn them into traps. And "only eliminating the biggest cause of safety issues." Memory safety is nowhere even close the biggest cause of safety issues in IT. For example, it is - for me personally - completely irrelevant. I never got hacked by a memory safety issue. There are entirely different things I worry about, which Rust makes harder to deal with, e.g. supply chain security.
• selfmodruntime 2y ago
  > monomorphization bloat Especially because the fix is so easy, it could just be fixed by the compiler on the fly. If you have a function fn a(arg: Into<C>) { expensive/extensive operations here } and call it two times a(&"test"); a(10); The compiler will generate two functions fn a_str(arg: &str) { /// expensive/extensive operations } fn a_u16(arg: u16) { /// expensive/extensive operations } This can be fixed by just proxying the duplicated call like this fn expensive_ops(arg: C) { // ... } fn a_str(arg: &str) { let _arg: C = arg.into(); expensive_ops(_arg); }