These biased bashes against C++ that advertise rust get somewhere between boring and annoying recently.
The main Rust community tries to discourage Rust "zealotry." For example, on /r/rust, the rules include:
4. When mentioning other languages, keep the discussion civil. No zealotry!
Anyway, as for your other question:
E.g. something like boost asio would be between hard to impossible to implement in Rust because the safety mechanisms disagree with callbacks that mutate state or Future objects (which are similar to callbacks).
I know that futures have been implemented several times in Rust, including in the standard library:
In general, multithreading primitives can be implemented using ordinary Rust libraries. Internally, these libraries use unsafe to do low-level threading work, but externally, they provide a safe API. The library author takes responsibility proving that their design is, in fact, thread safe.
If you know of specific boost asio features that can't actually be implemented safely in Rust, I'd love to know about them. I know that various people want to work on async I/O libraries for Rust after 1.0, and it would be nice to know about any major obstacles in advance.
These are futures that you only can synchronously wait on (like what is currently available as std::future). However there is no possibilty to attach continuations that run when the value of the future is available. E.g. like the C++17 concurrency proposals, C#'s `Task` type or Javas `CompletableFuture`. These all rely on storing some kind of callback or closure inside the Future.
That's not easy in Rust because it leads to situations where ownership is no longer obvious. The continuation might need to capture objects that are still needed locally (so you need something similar to Rc<RefMut<SomeThing>> ). In the most simply example's the continuation needs a mutable reference to the Future itself whereas the Future-producing operation also has one. And if you have possibilities that the continuation could run on another thread/executor than the calling thread (which is possible with the other languages) things get more complicated.
Regarding asio. You don't have to deep dive very much here:
Simply consider boost::asio::async_write(socket, buffer, [](error_code, bytes_transferred) { /* Do something with the result
*/ });
You need some mutable objects (like socket or the object that contains socket) locally AND you need acccess to them in your continuation. This will only work "safely" with garbage-collected or ref-counted types and these do still not seem to work for interfaces.
This will only work "safely" with garbage-collected or ref-counted types and these do still not seem to work for interfaces.
I'm not quite sure if I understand the problem you're describing. I can definitely share mutable objects between threads, and I can do so using abstract traits (aka "interfaces"). Here's an example:
I had to use a "box" here, because that's the easiest way to store objects of varying size that implement a specific interface. Experienced Rust developers may be able to simplify this a bit.
Is this what you were thinking about? Or did you mean something else?
The part that your example is missing is that one side uses the trait object (Common) whereas the other side uses the "normal" type (Foo or Bar) or another trait object view of the object. And the be able to cast between such "smart-boxed" types after you acquired one of them.
See the disucssion a little bit below for examples with Rc (it's the same problem but within a thread instead of between threads).
> 4. When mentioning other languages, keep the discussion civil. No zealotry!
This article still reads like zealotry. No tradeoffs are shown, only praise. C++ examples are alien. Like GP, I had the same experience with C++ templates being able to do more things than Rust's traits (like templating by a value).
I think the emphasis was meant to be on "the main Rust community". I would hope that most of us would try our best not to misrepresent other people's hard work. I definitely agree that whilst Rust's generics are far nicer to work with thank duck-typed templates, there are still gaps when it comes to matching C++'s expressive metaprogramming. Templating over values, constexprs and variadic type parameter lists are the main ones. I do know that the former two are planned, but that will have to be after 1.0.
The main Rust community tries to discourage Rust "zealotry." For example, on /r/rust, the rules include:
4. When mentioning other languages, keep the discussion civil. No zealotry!
Anyway, as for your other question:
E.g. something like boost asio would be between hard to impossible to implement in Rust because the safety mechanisms disagree with callbacks that mutate state or Future objects (which are similar to callbacks).
I know that futures have been implemented several times in Rust, including in the standard library:
http://doc.rust-lang.org/nightly/std/sync/struct.Future.html
In general, multithreading primitives can be implemented using ordinary Rust libraries. Internally, these libraries use unsafe to do low-level threading work, but externally, they provide a safe API. The library author takes responsibility proving that their design is, in fact, thread safe.
If you know of specific boost asio features that can't actually be implemented safely in Rust, I'd love to know about them. I know that various people want to work on async I/O libraries for Rust after 1.0, and it would be nice to know about any major obstacles in advance.