Announcement

Collapse
No announcement yet.

Busd Taking Shape As A D-Bus Broker Written In Rust

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

  • #41
    Originally posted by fitzie View Post

    i'm saying just because $FOO is a systems programming language, doesn't mean that every software written in it is a systems program, in this case busd. the developer seemed diligent, but when he started saying, and then "we throw the data into channels and so it's scalable" I was like, okay. one of the audience mentioned backpressure for example, but I'm not really sure he got it. I'm sure that busd is not a toy, but it's not really serious either. i'm not looking to switch away from dbus-broker any time soon.

    async methods in traits have some major implementation issues that prevent them from being used in a full and complete way. for example using async in a trait when using a trait object with static dispatch is the issue I ran into. looking into that I realized that there is a pile of well discussed issues with async in rust. there are some issues when mixing python sync/async, it's not even close to the split that rust has. and i'm sure it will be fixed in 2-3 years or 4-5 years, but that's way too long IMO. but I don't really want to turn this into a rust good/bad debate.
    The problem you mention is a more general limitation of the current handling of existential types in Rust (e.g. impl Trait in return positions) in traits. This includes async methods because of course that's what they desugar to. Yes that problem is currently unsolved and although there are proposals on how to tackle it, to my knowledge no solution has been decided on as yet. Note that there is nothing particularly unusual about that kind of situation, all languages have some relatively new features that are only partially supported. C, C++ and others are no different. Like you say, it's not about Rust Good or Rust Bad, among other reasons because the busd developers either don't have a problem there, or use some workaround: their software apparently works.

    I don't know why that would make busd "not serious". I haven't tried it, it may very well be not serious for some other reasons, but how is specifically this a reason? Again: async rust has currently limitations, everyone knows that, whoever uses it does so with the knowledge of what it can and cannot do, and busd seems to be using it just fine for what it needs. In practice no-one is going to use it instead of dbus-broker in the near future, that much is obvious, but this whole argument seems to me to be along the lines of "no-one serious would use a combustion engine to power a car because it wouldn't work if you try to run it upside down, at the bottom of an ocean".

    Comment


    • #42
      Originally posted by jacob View Post

      The problem you mention is a more general limitation of the current handling of existential types in Rust (e.g. impl Trait in return positions) in traits. This includes async methods because of course that's what they desugar to. Yes that problem is currently unsolved and although there are proposals on how to tackle it, to my knowledge no solution has been decided on as yet. Note that there is nothing particularly unusual about that kind of situation, all languages have some relatively new features that are only partially supported. C, C++ and others are no different. Like you say, it's not about Rust Good or Rust Bad, among other reasons because the busd developers either don't have a problem there, or use some workaround: their software apparently works.

      I don't know why that would make busd "not serious". I haven't tried it, it may very well be not serious for some other reasons, but how is specifically this a reason? Again: async rust has currently limitations, everyone knows that, whoever uses it does so with the knowledge of what it can and cannot do, and busd seems to be using it just fine for what it needs. In practice no-one is going to use it instead of dbus-broker in the near future, that much is obvious, but this whole argument seems to me to be along the lines of "no-one serious would use a combustion engine to power a car because it wouldn't work if you try to run it upside down, at the bottom of an ocean".
      i didn't call the deficiencies in async unusual, I called it incomplete, I'm glad we agree. I haven't had that experience with a programming language for a while, but i've been using python for a while, so that's on me. As for busd, you can watch the video yourself. I didn't promise to explain every reason why I consider it not serious and I don't plan on it. If you have a different conclusion then good for you.

      Comment


      • #43
        You know the author, zeenix147 , is in the thread right?! zbus and busd by extension seems pretty serious.

        Comment


        • #44
          Originally posted by zeenix147 View Post

          Rust is NOT a managed language. I didn't show memory usage because there was no reason to. If you have done any research whatsoever, you'd know that Rust's performance comes pretty close to C (even better than C++).



          Push back where? Do you see any assembly in the dbus-broker or dbus-daemon code? We snowflakes also write unsafe code where it bring performance benefits and even write C or assembly when needed.
          It’s a troll

          Comment


          • #45
            Originally posted by cb88 View Post
            They should just switch to binder... which is already being rewritten in rust, and stop wasting time with dbus which is essentially a failure.
            It was before I started bookmarking everything I might want to refer back to, but one of the kernel maintainers wrote a blog post about Binder when it got upstreamed... TL;DR: If you don't use the matching SELinux rules in enforcing mode, like Android does, then it's fundamentally insecure and allows trivial privilege escalation.

            (It also optimizes for different use-cases than D-Bus, which means that one will be notably slower or faster than the other depending on what kind of higher-level behaviours you're using.)

            Comment


            • #46
              Originally posted by fitzie View Post

              i'm saying just because $FOO is a systems programming language, doesn't mean that every software written in it is a systems program, in this case busd. the developer seemed diligent, but when he started saying, and then "we throw the data into channels and so it's scalable" I was like, okay. one of the audience mentioned backpressure for example, but I'm not really sure he got it. I'm sure that busd is not a toy, but it's not really serious either. i'm not looking to switch away from dbus-broker any time soon.

              async methods in traits have some major implementation issues that prevent them from being used in a full and complete way. for example using async in a trait when using a trait object with static dispatch is the issue I ran into. looking into that I realized that there is a pile of well discussed issues with async in rust. there are some issues when mixing python sync/async, it's not even close to the split that rust has. and i'm sure it will be fixed in 2-3 years or 4-5 years, but that's way too long IMO. but I don't really want to turn this into a rust good/bad debate.
              I actually really like how async works in Rust. It's quite low-level and simple, even usable in nostd. It's also easily combined with non-async code if you know what you are doing and even can work with other languages' async across FFI. In the end it's a really slim layer that not only improves efficiency, but also simplifies working with multiple io sources and timers. All problems that I had with it have already been solved, most of them - long ago, cannot imagine something I could not achieve with it.

              What static dispatch issues have you encountered with "impl Future" in the trait?

              Comment

              Working...
              X