Originally posted by fitzie
View Post
Announcement
Collapse
No announcement yet.
Busd Taking Shape As A D-Bus Broker Written In Rust
Collapse
X
-
Originally posted by jacob View Post
By that analogy C with pthreads is not a system language either. The point is that the assumption that using some sort of runtime system="managed"=slow and inefficient is absolutely not true.
Leave a comment:
-
They should just switch to binder... which is already being rewritten in rust, and stop wasting time with dbus which is essentially a failure.
Leave a comment:
-
I thought I'm not seeing this day in my lifetime: A rust vs. C thread that mostly doesn't conflate C with C++.
That's quite remarkable.
Leave a comment:
-
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.
Leave a comment:
-
Originally posted by fitzie View Post
rust with tokio async (that busd uses) is not a systems programming language. change my mind.
- Likes 1
Leave a comment:
-
Originally posted by bug77 View Post
Rust is mostly meant to be a systems programming language. What "new" do you need in that area? What "new" are you expecting in any area, really?
On a more serious note, a DBus broker seems like a premier candidate for Rust, memory errors in such a component can open some serious holes in a system.
Leave a comment:
-
Originally posted by Vorpal View PostI'm a bit surprised by the choice of tokio, since zbus uses async-std instead. I wonder what the reason for tokio here was.
- Likes 1
Leave a comment:
Leave a comment: