When threads are passing messages around, and come up with fabulous improvements in processing time, that sounds to me like the job includes I/O of some kind. Threads are a great way to get around I/O delays - the graphic user interface being of course an example.
They’re also a good way to shoot yourself in the foot, and some programmers - even an ex-Be engineer, I think, though I don’t remember who - have argued that the pervasive use of threads in the Interface Kit is asking for trouble. It’s kind of a religious argument, and indeed if you religiously follow good practices with threads you don’t have to worry about it too much.
Which is why Mozilla is rewriting Firefox’s rendering engine in Rust… they wanted a concurrent and multithreaded renderer, but C++ was too risky to do it in. Of course you can do it, but you have to be very disciplined… and people make mistakes. So they punted the responsibility for that to the language.
I’d be interested to hear how Rust vs. C++ makes any difference with thread safety issues. Honestly I’m kind of skeptical. There are languages that go all out for concurrency, like Erlang, but it’s my impression that they typically wouldn’t help a bit on Haiku because they implement their own multithreading rather than using the OS threads. (Though it has been a very long time since I looked at Erlang, and I couldn’t say for sure about that specific example.) More in general, functional programming advocates claim that FP is better for thread safety, because of its pure data model, that puts data mutability within strict limits where it’s easier to rigorously account for data shared between threads. That doesn’t sound like Rust, though.
Rust’s language manual has a whole chapter about their thinking on concurrency (which is what threads are) named Fearless Concurrency.
They argue that their focus on memory safe code, knowing who “owns” what at all times, applies to threads too, except that it’s harder for humans to reason correctly about when the thread’s ownership might matter in the concurrency case than for things like a method call.
The most common argument in this and most other cases from C++ advocates is “Oh, I could do all that in C++”. OK, well, did you? Did every single library or component you’re using? In Haiku’s case of course the answer is a violent “No” because Haiku is largely a re-implementation of the 1990s BeOS which pre-dates lots of this work.
At a casual read, they offer “channels” (see 1990s BeOS message ports), and mutexes (see 1990s BeOS BLooper::Lock() among other things.) If someone really liked the exact syntax etc. of the Rust versions, could they not be implemented in modern C++?
I am one of the few people here who knows both BeOS/Haiku and their style of C++, as well as Rust. Rust deeply tracks ownership of memory in a way C++ cannot do. It basically enforces good programming practices that have to be manually enforced in C++. Rust prevents data races and multiple threads accessing the same data at a core level.
Of all the operating systems, Haiku offers the most hope in doing threading in C++ with minimal errors, because the style of the API and structure of applications requires a message-passing style. It is still possible to screw up. Threaded programming is hard.
Haiku won’t ever become a Rust operating system. I like Rust, but it is really complicated, almost to the level of C++. If you want a Rust OS, check out Redox: https://www.redox-os.org/
As I said in the recent Rust thread here in the forums, I think Rust could have a place on Haiku. It could be a great system to write some really robust servers (in the sense of app_server and media_server, not web servers.) I think that long term Rust (and other languages) should become first class citizens for making Haiku apps.
But I don’t see the kernel being switched, nor large portions of Haiku being rewritten in Rust. It just isn’t worth it. But for cross-platform development of really fast applications, Rust is a better choice than C++ in my opinion. I intend to get our Rust port (we do have one) updated, and see what I can to start integrating it with some of the Haiku Kits. But this may take me some time.
I think it’s already up to date? At least nielx’s most recent recipe was merged just a few weeks ago and packages are in the depot.
Yes, we have a more up-to-date Rust package than I thought, version 1.32.0. I was basing my knowledge on the http://rust-on-haiku.com/ site which is obviously a bit behind.
Of course because of the 6 week release cadence there is now 1.33.0, so we are a little bit behind, but I don’t think it is a big deal because at least we have a “Rust 2018” compatible version. If Rust becomes “more official” in Haiku because of my work, or someone else’s, we may want to see what we have to do to have an official Rust builder. @nielx probably knows more about that than I do.
But thanks for this, it means I can start hacking on the fun stuff ASAP. Though I have a bunch of C++ Haiku bugs I want to work on first…
The most recent recipe is for 1.32.0. Actually, 1.33.0 is also built, but so far I haven’t made it into a recipe yet. The rust-on-haiku site is outdated, and the https://github.com/nielx/rust project is more up to date. It’s on my list to redirect the rust-on-haiku site to there.