Announcement

Collapse
No announcement yet.

Rust 1.62 Released With Faster Mutexes On Linux, Bare Metal x86_64 Target Promoted

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Rust 1.62 Released With Faster Mutexes On Linux, Bare Metal x86_64 Target Promoted

    Phoronix: Rust 1.62 Released With Faster Mutexes On Linux, Bare Metal x86_64 Target Promoted

    Rust 1.62 is out today as the latest update to this popular systems programming language with a few notable changes...

    https://www.phoronix.com/scan.php?pa...-1.62-Released

  • #2
    Does a better standard Mutex matter when parking_lot exist? That's infamously one of the examples of things that should just be left out of the standard library and left to an external library, so it can benefit from rapid development and independent releases, instead of relying on the rest of the language to be shipped.

    Comment


    • #3
      Will this speed up firefox?

      Comment


      • #4
        Still no async functions in traits. 😥️

        What else do you miss in Rust?
        Anything you want from Rust? Anything you dislike about Rust?

        Comment


        • #5
          Originally posted by Ironmask View Post
          Does a better standard Mutex matter when parking_lot exist? That's infamously one of the examples of things that should just be left out of the standard library and left to an external library, so it can benefit from rapid development and independent releases, instead of relying on the rest of the language to be shipped.
          Given that Rust releases every 6 weeks, I think this is not actually an issue, and I do think that a mutex is important enough to warrant being a part of the standard library if possible.

          Comment


          • #6
            Originally posted by uid313 View Post
            Still no async functions in traits. 😥️
            Native support will likely take some time because implementing it is hard (for a starter, it depends on GATs, which are not stable yet, but I think there are more issues). What about using the async-trait crate for the time being? It's not ideal (it requires heap allocation due to type erasure for the time being), but it works well enough so that even the compiler suggests its usage.

            Comment


            • #7
              I have basically given up on async in Rust, it's a lost cause. I really like this blog post about how unnecessary it really is: https://maciej.codes/2022-06-09-local-async.html
              Like, how often do you *really* need it? I know there are plenty of valid use cases, but I feel like people overuse it just to avoid entangling the red path/green path too much, or because they have no idea what their threading model is like and don't want to know, which reminds me of how people relied on GC to pretend to not have to care about memory, until Rust showed us a human way to care about memory that doesn't involve pretending it doesn't exist. I kinda learned to segregate async Rust code into as few places as possible and to actually care about what's running where. Unless you're writing a massively parallel server which the likes of Erlang/Elixir would be more appropriate, you usually can do without async.

              Comment


              • #8
                Originally posted by uid313 View Post
                Still no async functions in traits. 😥️

                What else do you miss in Rust?
                Anything you want from Rust? Anything you dislike about Rust?
                I miss the standard OOP features, like classes, inheritance, and exceptions.
                Don't take me wrong. I'm not saying they're better than the Rust way.
                In fact it's undeniable eg: that composition can be better than inheritance and so on.

                That said, sometimes the old, boring, not scalable, way of doing things can be easier.
                Also, I'm not saying that I want this instead of that. I'd like to have both.
                I mean, I want to use Rust more, but maybe it's a little too opinionated for my taste.
                It's entirely possibile that I suck at programming.
                Or maybe a little bit of both

                Comment


                • #9
                  Updated: https://t2sde.org/packages/rustc

                  Comment


                  • #10
                    Originally posted by Ironmask View Post
                    Does a better standard Mutex matter when parking_lot exist?
                    For my programs, the new std implementation is now faster than parking_lot, plus it lets me remove a bunch of third-party dependencies (faster build times, less bandwidth waste, etc.) It's a pretty nice upgrade!

                    Comment

                    Working...
                    X