From a language architecture standpoint and not an ecosystem standpoint, what might be some things where you’d really not want to use Rust, either because of some limitation that prevents it from doing it or just because it’d be massively annoying to write to the point of significantly reduced productivity? What about Rust makes it unsuitable, and what language paradigms are the best for it?

I hear a lot about how the things that Rust is not good for, JIT compilation with a garbage collector is usually the best solution, and vice versa. How true is this?

    • Ephera@lemmy.ml
      7·
      3 years ago

      Yeah, GUIs in general are messy, almost by necessity. And Rust has a strong focus on correctness, which does not mesh well with messy.

      As an example, it happens that you don’t yet have a certain value that’s supposed to be shown in the GUI, but it also doesn’t matter, because that GUI element isn’t actually visible yet.
      In many typical frontend languages, you would set that to null and be done with it. Rust doesn’t have null and while you can make everything an Option-type, that’s relatively clunky, for how commonly you need such a workaround.

      Obviously, though, constantly throwing around null isn’t great either. The compiler cannot help you at all anymore.
      So, I am still hoping that a new paradigm emerges out of all of this, which is better for GUIs in any language. Basically put more thought into actually resolving the issue, rather than standardizing on the dirtiest workaround.

        • Ephera@lemmy.ml
          2·
          3 years ago

          I mean, for what it’s worth, my own definition of ‘beautiful code’ includes the properties “reliable” and “human-readable/-writable”. I do not like clever code or code that hides errors away.

          I do work in a company, not in academia, but even for my personal projects, that’s my goal. It’s just a necessity when you want to collaborate with others or your future self.

        • pinknoise@lemmy.ml
          1·
          3 years ago

          Option is rust’s null. And matches are everywhere because of it.

          And if let’s - so what?

          C++ makes working with null pointers so beautiful.

          How? You still have to check wether it’s NULL or not.

          Businesses want reliable software

          No they want quick turnaround, so they can make more profit. Thats the opposite of reliable software. Thats why most commercial software is such a buggy mess.

          • southerntofu@lemmy.ml
            2·
            3 years ago

            How? You still have to check wether it’s NULL or not.

            I think that’s the parent’s point: in C/C++ you don’t have to deal with null. You can just pass it around and potentially start unintended/undefined behavior. While in Rust, it’s a compile-time error if you don’t unwrap the option somehow (eg. if let Some(content) = optional_content).

            So yes it’s more concise and “beautiful”, but you’ll probably bite your own hand at some point playing this game

            • pinknoise@lemmy.ml
              2·
              3 years ago

              How is it more beautiful? You have to deal with null pointers when you want to use the pointer anyway, if you don’t you will get a runtime error, or worse, your program will keep running in an unintended state.

              • southerntofu@lemmy.ml
                2·
                3 years ago

                yes, that was exactly my point. You can just use a pointer without checking it, which is aesthetically more pleasing, but will produce garbage :)

    • brombek@lemmy.ml
      2·
      3 years ago

      Rust kinda sucks for writting windows guis. This guy at microsoft spent like two years making bindings and you ended up needing to use unsafe everywhere.

      This looks like a big one and common theme. You can in theory wrap any C API with Rust but it does not mean it is possible to make it safe in Rust - the programming models may be incompatible. Worst is that in C you can use different practices around “ownership” of objects and mix them up in single program - this will make it very difficult/impossible to wrap it in safe Rust and waste a lot of time trying.

      It would be good to have some good practices around this so people can recognize what is worth wrapping and what is better done from scratch in Rust.

    • AgreeableLandscape@lemmy.mlOPM
      2·
      3 years ago

      Rust does not like undefined behavior.

      Can you elaborate this? Is it like when your program wants an integer between 1 and 5 and it gets -420?

      • southerntofu@lemmy.ml
        2·
        3 years ago

        Can you elaborate this? Is it like when your program wants an integer between 1 and 5 and it gets -420?

        This is a matter of correctness: does your program behave as expected? (Rust can help with this with eg. types to prevent integer overflow)

        What we mean with undefined behavior is it’s actually undefined. There’s quite a lot of constructs you can use in C which will get compiled to different instructions by the compiler and behave in unexpected ways. Or even when compilers agree on a certain way to do it, use-after-free and other patterns can lead your program to taking unpredictable turns.

        So, just because your program doesn’t have undefined behavior doesn’t mean it’s correct. But if it’s correct, it can’t have any undefined behavior. If you’ve ever noticed how most programs written in C/C++ seem to have hard-to-reproduce bugs (eg. desktop environments) you’re very likely to have encountered undefined behavior in the wild.