• Zangoose@lemmy.world
    2392·
    7 days ago

    The irony of this meme being posted from a platform written in rust is pretty great ngl

  • LordKitsuna@lemmy.world
    952·
    7 days ago

    I get the joke, but rust is actually pretty heavily used in the backend of services theae days. Cloudflare, Amazon, Dropbox, just to randomly name a few off the top my head. Have pretty heavily invested it into their back ends for more reliable service.

  • vga@sopuli.xyz
    55·
    7 days ago

    Rust is fearlessly upholding the whole thing even without touching it. Incredible!

  • Simulation6@sopuli.xyz
    451·
    7 days ago

    Rust is actually awesome in many ways. No always the right solution, but nice to have in your toolbox.

    • Croquette@sh.itjust.works
      192·
      7 days ago

      Where would you say Rust isn’t the right solution?

      We always hear how great Rust is, but I’d be curious to know where it isn’t.

      • rumba@lemmy.zipEnglish
        23·
        6 days ago

        Rust provides safety and protection.

        Rust isn’t as rapid as other options, has less library support, and porting existing code is relatively difficult.

        IMO because of the workarounds you need to do to handle the memory safety, you end up with a lot more hard to solve bugs than you do with conventional languages. It should be noted however that the bugs don’t end up being security vulnerabilities like they do in conventional systems.

        If you have something that needs to be structurally sound and/or you have enough talented people willing to work on it, it’s a great option. If it needs to be fast and cheap and you don’t have a gaggle of rust developers on hand and it’s already written in another language, it might not be the best solution.

        • Croquette@sh.itjust.works
          5·
          6 days ago

          I come from embedded C, so what you describe doesn’t feel alien to me (minus the security vulnerabilities haha)

          I much prefer working with Rust restrictions than a higher level language without hard types because I am used to it.

        • LimaJ@techhub.social
          23·
          6 days ago

          @rumba @Croquette They’re is a lot of people scrambling to rewrite existing c projects in rust for what?
          for example ffmpegs rust rewrite is slower than the c version we need more maintainers rather than creating new rust alternatives that have no purpose

          • rumba@lemmy.zipEnglish
            81·
            6 days ago

            If you want to ignore re-making things out of memory-safe technology as an advancement, we don’t really have anything to talk about here.

            • LimaJ@techhub.social
              01·
              6 days ago

              @rumba making new projects in rust sure cool but when big projects that most of the world relies on etc ffmpeg crucially need maintainers and contributions rust isnt needed and is a waste of resources when C can do it better, faster and easier rust is a fast fade that will likely remain in the shadow of C. Tbh your glazing rust without looking at both sides of the argument so the picture op posted really is true

              • rumba@lemmy.zipEnglish
                1·
                6 days ago

                Ahem…

                If you want to ignore re-making things out of memory-safe technology as an advancement, we don’t really have anything to talk about here.

          • Croquette@sh.itjust.works
            1·
            6 days ago

            I know Rust superficially. I use it to create simple tests for my embedded projects, so mostly just serial terminal with keyboard inputs.

            It works a lot better for me than python because Rust is a lot closer to C than python.

            So I cannot comment on Rust shortcomings. I was interested in knowing for what kind of projects Rust wasn’t good.

      • tyo_ukko@sopuli.xyz
        3·
        5 days ago

        We always hear how great Rust is, but I’d be curious to know where it isn’t.

        • In any project that’s sufficiently advanced and written in any other language. You don’t simply do a rewrite of 100k+ LOC just because you want to use Rust.

        • Somewhere where you’d rather use a scripting language like Python. I.e., rapid prototyping or gluing together some infra components.

        • A situation where your team’s expertise is in some other language.

        • A situation where a library/framework is native/only available for a certain language.

        Few of these are strictly technical requirements. It’s obvious that you can use almost any language to do almost anything, including Rust, if that’s what you prefer. However, the context matters in the real world.

        All this being said, I wish I had a chance to write Rust professionally. It’s a neat language.

      • NeatNit@discuss.tchncs.de
        81·
        6 days ago

        Never used Rust but I’d like to point out the YouTube channel Low Level which covers security vulnerabilities (CVEs). He ends each video with “would Rust have fixed this?” and it’s pretty interesting.

        A very recent one is this: https://youtu.be/BTjj1ILCwRs?t=10m (timestamped to the relevant section)

        According to him, when writing embedded software in Rust (and UEFI is embedded), you have to use Rust in unsafe mode which basically disables all the memory safety features. So in that kind of environment Rust isn’t really better than C, at least when it comes to memory safety.

        That’s not to say Rust isn’t still a good option. It probably is.

        Again, I never used Rust so I’m just parroting stuff I’ve heard, take all of this with a grain of salt.

        • calcopiritus@lemmy.world
          12·
          6 days ago

          Rust doesn’t have “safe” and “unsafe” modes in the sense your comment alludes to.

          You can just do the little unsafe thing in a function that guarantees its safety, and then the rest of the code is safe.

          For example, using C functions from rust is unsafe, but most of the time a simple wrapper can be made safe.

          Example C function:

          int arraysum(const int *array, int length) {
    int sum = 0;
    while (length > 0) {
        sum += *array;
        array++;
        length--;
   }
}

          In rust, you can call that function safely by just wrapping it with a function that makes sure that length is always the size of array. Such as:

          fn rust_arraysum(array: Vec<i32>) -> i32 {
    unsafe{ arraysum(array.as_ptr(), array.len() as i32)}
}

          Even though unsafe is used, it is perfectly safe to do so. And now we can call rust_arraysum without entering “unsafe mode”

          You could do similar wrappers if you want to write your embedded code. Where only a fraction of the code is potentially unsafe.

          And even in unsafe blocks, you don’t disable all of the rust checks.

          • NeatNit@discuss.tchncs.de
            4·
            6 days ago

            Thanks for this. I was paraphrasing (badly, it seems). The video actually says it better:

            To write code that lives in an embedded environment, it has to run in this mode in Rust called “no standard” (#![no_std]) and this mode called “no main” (#![no_main]). Basically you have no access to any of the core utilities in Rust, you have to write a lot of them yourself.

            He then explains how embedded code necessarily has global mutability which is “the antithesis” of Rust development.

            So yeah, you could make all of those wrappers, but at the end of the day you’ll end up with about the same amount of “unsafe” code as you would making the same thing in C++.

            Edit: but if what you said still applies, it does seem like Rust would watch your back somewhat better than C++ would in that it wouldn’t even compile unsafe operations outside of unsafe blocks, unlike C++ to the best of my knowledge where you kind of have to review the code yourself to make sure it only uses the appropriate wrappers.

        • Croquette@sh.itjust.works
          3·
          6 days ago

          I am glad for your comment because I work with mcus and embedded solutions in C, so Rust, in that case, wouldn’t be neccesarily safer than C.

          I will have to look into it. I need to do 30h of training every two years, so I will learn Rust regardless, but I was thinking about eventually switching to Rust for embedded projects. Might just keep Rust as my scripting language because it is easier for me than Python

          • NeatNit@discuss.tchncs.de
            4·
            6 days ago

            It’s an interesting discussion. As someone who doesn’t actually deal with this and who literally never used Rust, I feel out of me depth. But it does sound like Rust has much better mechanisms to catch a programmer’s mistake. See my reply to the other guy.

  • exocortex@discuss.tchncs.de
    363·
    7 days ago

    I get the meme (though why was this single unstable point - imagemagick in the original xkcd - removed? To make the left side seem more stable clmpared to the original idea?), it might be trueish atm. But with rust I feel that a lot of projects that are rewritten in rust are quicker arriving at a “finished” (or almost finished) state where they are more or less just tools being used without much discussion anymore. I guess a lot of commonly used tools already use Rust in some way, but i rarely is an issue which makes this discussion-worthy or generates enough conflict in order to raise awareness outside.

    I have a hunch that open-source rust-devopment is less of a hassle as a lot of discussion about code or the quality therof is simply avoided by a stricter compiler. If the code committed compiles with rustc there’s less possibility of it breaking other things in the codebase or containing hidden dangers that need to be discussed. Overall less friction, less overhead and distruction from the actual coding.

    • _stranger_@lemmy.world
      21·
      6 days ago

      Old programs everyone agrees do exactly what they should are a perfect target for “black box” porting to a new language, where the only criteria for success are “it should function exactly like before, just more efficiently, while being more maintainable”

  • The Bard in Green@lemmy.starlightkel.xyzEnglish
    361·
    7 days ago

    I’m working with some Rust right now that is 100% a big mess…

    It’s consistently either the Rust or the Docker components that fail to build. In fairness, it’s a VERY big and complex application.

    • lad@programming.devEnglish
      6·
      7 days ago

      We had to use Nix to build Rust services and make containers of them. It works pretty well, except with Nix 2.29 and 2.30 where it is broken for some reason

    • GreenKnight23@lemmy.world
      820·
      7 days ago

      docker doesn’t really fail to build unless something upstream fails, like lib builds that don’t have the proper dependencies installed. I’d still count those failures as rust fails 😂

      that said, I worked with a kid that was trolling rust package managers hard by squatting on common library names because they refused to resolve the issues of squatting. dick move but clearly educated me on the toxicity of the rust community and why I should avoid it.

  • okamiueru@lemmy.world
    102·
    7 days ago

    Considering that FFI is very much a thing, I’m finding it difficulty to understand the point it’s trying to make.

  • OpenStars@piefed.socialEnglish
    126·
    7 days ago

    Wait, but I don’t see how it’s relevant in the smallest of ways… OOOOOH! (/s, bc obviously we all knew that already:-P)