• soulsource@discuss.tchncs.de
    link
    fedilink
    arrow-up
    17
    ·
    1 year ago

    I can only speak out of my own experience, which is mostly C++, C#, C and Rust, but I also know a bit of Haskell, Java, Fortran, PHP, Visual Basic, and, to my deepest regret, also JavaScript.

    For additional context: I have been working in game development for the last 7 years, my main language is C++ for Unreal, but I’ve also worked on some Unity projects with C# as main language. Before I switched to game dev I worked in material science, and used C, mostly. I use Rust for my spare time projects, and the game company I work at is planning to introduce it into our Unreal projects some point later this year.

    Of all the languages I mentioned above, (Safe) Rust and Haskell are the only ones that have not yet made me scream at my PC, or hit my head against the desk.

    So, some of the reasons why I personally love Rust:

    • Rust is extremely simple compared to the other languages I mentioned above. If you read the official introduction you know all you need to write Safe Rust code.
    • Rust’s syntax is elegant. It’s not as elegant as Haskell, but it’s a lot more elegant than any C-based language.
    • Rust is (mostly) type safe. There are (nearly) no implicit conversions.
    • Rust is memory-safe, without the runtime overhead that garbage collected languages incur.
      • This is a bit of a neutral point though. The Rust compiler will complain if you make mistakes in memory management. Unlike in managed languages, you still need to do the memory management by hand, and find a working solution for it.
    • The memory management model of Rust (“borrow checker”) makes data dependencies explicit. This automatically leads to better architecture that reflects dependencies, because if the architecture doesn’t match them, development will become an uphill battle against the borrow checker.
    • Due to the borrow checker, you can use references extensively, and rely on the referenced object to valid, and also that it is up-to-date (because it cannot be muted or go out of scope as long as you hold the reference).
    • Traits are an amazing way to abstract over types. Either at zero-cost (static dispatch), or, in the rare cases where it’s needed, using virtual function tables.
    • Rust aims to have no undefined behaviour. If it compiles the behaviour of the code is well defined.
      • This, together with the borrow checker, ensures that there are (nearly) no “weird bugs”. Where in C++ one quite regularly hits issues that at first glimpse seem impossible, and only can be explained after several days of research on cppreference (“oh, so the C++ standard says that if this piece of code gets compiled on a full moon on a computer with a blue power LED, it’s undefined behaviour”), that almost never happens in Rust.
    • Macros in Rust are amazing. There are macros-by-example that work by pattern-matching, but there are also procedural macros, which are Rust functions that take Rust code as input, and generate Rust code as output. This gives you amazing power, and one of the most impressive examples is the Serde serialization framework, that allows you to add serialization to your data types simply by adding an attribute.
    • Tooling for Rust is pretty good. The Rust compiler is well known for its helpful error messages. The rust-analyzer plugin for Visual Studio Code is great too. (It also works with vim, Qt Creator and others, but the but Visual Studio Code works best imho.)

    The points mentioned above mostly apply to Safe Rust though. Unsafe Rust is a different story.

    This brings us to the downsides. Rust isn’t perfect. Far from it, actually. Here are some of the things that aren’t great about Rust.

    • No Higher Kinded Types. This is my main issue with Rust. Even C++ has them (as usual for C++ in a horrible un-ergonomic and utterly confusing way). If Rust had Higher Kinded Types, the language could have been simpler still. For instance, there would have been no need for the async keyword in the language itself.
    • Unsafe Rust is hard. In my opinion even harder than C++, because of Rust’s aliasing rules. Unlike C++, Rust doesn’t allow mutable memory aliasing. That’s because mutable aliasing can never happen in Safe Rust, and not supporting it improves performance. This means that when writing Unsafe Rust, one has to be careful about aliasing.
      • Luckily one only rarely needs Unsafe Rust, usually only in order to call functions from other languages. Still, it’s hard, and I’d generally suggest to use an automated code generator like cxx.rs for interfacing with other languages.
    • Interior Mutability. I understand why it exists, but it breaks a lot of the guarantees that make Rust a great language. So, my conclusion is that one should avoid it as much as possible.

    However, the upsides clearly outweigh the downsides imho.

    tl;dr If a (Safe) Rust program compiles, chances are pretty high that it also works. This makes programming with it quite enjoyable.

    • starman@programming.devOP
      link
      fedilink
      English
      arrow-up
      3
      ·
      edit-2
      1 year ago

      to my deepest regret, also JavaScript

      I can relate. And thanks for this high-effort comment.

    • Walnut356@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      For downsides, i’d like to add that the lack of function overloading and default parameters can be really obnoxious and lead to [stupid ugly garbage].

      A funny one i found in the standard library is in time::Duration. Duration::as_nanos() returns a u128, Duration::from_nanos() only accepts a u64. That means you need to explicitly downcast and possibly lose data to make a Duration after any transformations you did.

      They cant change from_nanos() to accept u128 instead because that’s breaking since type casting upwards has to be explicit too (for some reason). The only solution then is to make a from_nanos_u128() which is both ugly, and leaves the 64 bit variant hanging there like a vestigial limb.

    • anlumo@feddit.de
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Unlike C++, Rust doesn’t allow mutable memory aliasing. That’s because mutable aliasing can never happen in Safe Rust, and not supporting it improves performance. This means that when writing Unsafe Rust, one has to be careful about aliasing.

      Note though that it’s perfectly fine to have multiple mutable raw pointers pointing to the same data. The problem only happens if you try to convert them into references.

        • TehPers@beehaw.org
          link
          fedilink
          English
          arrow-up
          0
          ·
          edit-2
          1 year ago

          If you run Miri on your code (Tools -> Miri in the Playground), it actually seems to complain about UB. I’m not experienced enough with unsafe rust to translate that error message to something meaningful though.

          Edit: Wait, that’s the while_here_it_isnt method. I’m clearly tired…

            • TehPers@beehaw.org
              link
              fedilink
              English
              arrow-up
              1
              ·
              edit-2
              1 year ago

              Edit: Lemmy decided to completely butcher my comment, so I’ve replaced all the ampersands with %. Sorry, this will look a bit funny.

              You (and they) are right that aliasing pointers is fine. I was running Miri on your playground link, and it gave the expected results. I was just too tired to realize that it was saying your failure case (where you did multiple mutable aliasing with borrows) caused UB and that your success case (where you did multiple mutable aliasing with pointers) did not cause UB.

              Generally speaking, the rules around aliasing only apply to borrows in Rust, from my understanding. Any code that creates two %mut borrows of the same value is immediate UB. Any code that could possibly cause that to happen using safe code is unsound. Since your method operates only on the raw pointers, no aliasing rules have been broken, however the compiler also can’t optimize around your code the same way it could had you used regular borrows (assuming it’s possible). At a lower level, this is reflected by the compiler telling LLVM that %mut T values (usually) are not aliased, and LLVM applies optimizations around that. (Note that UnsafeCell is a bit of a weird case, but is fundamental to how the other cell types work.)

              This is actually why shared pointers like Rc and Arc only give you shared borrows (%) of the values contained in them, and why you’re required to implement some kind of interior mutability if you want to mutate the shared values. The shared pointer cannot guarantee that two borrows of the same value are not active at the same time, but does allow for shared ownership of it. The Cell/RefCell/Mutex/etc types verify that there is only one active %mut T (unique borrow) of the inner value at a time (or in Cell’s case even allows you to mutate without ever receiving a %mut T).

              Note that while %T and %mut T are often referred to as “immutable” and “mutable” references, it’s probably more accurate to refer to them as “shared” and “unique” references. Mutability is not actually tied to whether you have a %T or a %mut T. This is trivially shown by looking at the Atomic* types, which only require a %self for their store operation.

  • luckystarr@feddit.de
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    Easy. If my editor shows no errors anymore, it will run, instead of crash due to my ignorance of alignment, leaks, etc.

    I’m just a lazy developer, so blame me if you want. I just don’t want to learn that stuff if I don’t really really need to. I have to memorize enough already.

  • anastasiastefanyuk@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    10 months ago

    Rust is super popular among devs because it’s really safe and efficient. Plus, it handles memory management without needing a garbage collector, which cuts down on bugs and security issues. If you’re looking to scale up your project, you might want to consider looking into hire remote Rust developers. They can help you leverage all the cool benefits of Rust in your next project!

    • Tobias Hunger@programming.dev
      link
      fedilink
      arrow-up
      11
      ·
      1 year ago

      Watch out: That mindset is what got me into Rust in the first place!

      I was so fed up with everybody drowning on about Rust that I thought I need to read up on it a bit so that I can argue against the hype. I am a seasoned C++ dev after all, I use a language that I picked because it allowed for robust and fast code. What could Rust add on top of that?

      Well, I have a job working almost exclusively with rust now and do not plan to ever go back.

      • intelati@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        1 year ago

        As mostly a novice (interested, but unpracticed) programmer I see it as an updated/upgraded C family language?

        I don’t think there would be a large learning curve?

        • Tobias Hunger@programming.dev
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          The basics are all the same:. memory, cpus and caches in between ;-)

          But rust does approach many things very differently from C or C++. Learning those new approaches takes time and practice.

    • keardap@lemmy.selfhost.quest
      link
      fedilink
      arrow-up
      10
      ·
      1 year ago

      Working on scientific code, Rust is amazing.

      We used to either code in C or Python. Now Python is only used for data analysis pre-post computation.

      The code is as fast as in C, the compiler is great at helping us prototype without bugs, memory usage is lower.

      We dropped C complelty and reducing our usage of Python.

    • sirdorius@programming.dev
      link
      fedilink
      arrow-up
      9
      arrow-down
      1
      ·
      edit-2
      1 year ago

      So the survey of 90k developers on one of the most popular programming sites, have it as the most “want to reuse it in the future” language for 8 years and this is somehow a minority?

      What is your data source for this enlightened majority that is opposed to it? Your own opinion?

      • Generally the programmers that visit these kinds of websites, let alone participate in a survey, are the enthusiast programmers who are much more likely to be interested in exploring a new language in the first place.

        There’s a considerable potential for a selection bias here. Not that this disproves the survey, but generally these kinds of surveys tend to be a little bit ahead of the curve, so to speak.

        • sirdorius@programming.dev
          link
          fedilink
          arrow-up
          2
          arrow-down
          1
          ·
          1 year ago

          True, and in my experience these are the people that are most passionate, end up more easily in senior/lead roles and have a better say in what tech stack get used tomorrow. So I’m betting some of my time and career development on Rust.

    • Thisfox@sopuli.xyz
      link
      fedilink
      English
      arrow-up
      7
      arrow-down
      4
      ·
      1 year ago

      Coding is and always has been fad driven. The article admits Python and so on are more popular.

      • snaggen@programming.dev
        link
        fedilink
        arrow-up
        3
        arrow-down
        2
        ·
        edit-2
        1 year ago

        Yes, but all programmers have a love/hate relationship to their languages and toolchains. When I started off back in the 90:s, my prefereed language was Perl, it was amazing, but it was also a nightmare in some aspects… and unfortunately the larger the project the larger the nightmares. I assume Python is probably pretty much the same, even though I have avoided to work with dynamic languages in very large scale projects due to the support nightmares that comes with them. So I assume the Rust cult, is based on the fact that the rust frustration comes a lot from the strictness of the language, but that becomes less of a problem the more you use it (since your skills improve) and at that point the strictness instead gives the reward of reliability and efficiency.

        So, while dynamic languages may frustrate you the more you use it (since the projects grows and it is a nightmare to maintain), rust will instead reward you over time.