5 ms·

These biased bashes against C++ that advertise rust get somewhere between boring and annoying recently. The main Rust community tries to discourage Rust "zealo

by ekidd 12y ago

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: http://doc.rust-lang.org/nightly/std/sync/struct.Future.html 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.

p0nce 12y ago
> 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).
- bjz_ 12y ago
  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.
  - p0nce 12y ago
    Exciting! It will be interesting to see if duck-typing prove more useful or not in the Rust meta world, language wars aside.
Matthias247 12y ago
Regarding the futures: 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.
- ekidd 12y ago
  Interfaces can sometimes be tricky, especially if you're also working with lifetimes, because there's no way to write "T<'a>" for a generic type. There are are few other gotchas like this. Some of these will get better once associated types land. But yeah, trying to simultaneously manage interfaces, lifetimes and callbacks sometimes requires serious Rust knowledge—and at least for now, you may run into hard barriers. You need some mutable objects (like socket or the object that contains socket) locally AND you need access to them in your continuation. If you're planning on writing to objects from inside a continuation, while you also write to them from your main code as well, you're going to have to think things through pretty carefully in any language, or else the two writers will stomp on each other. Rust has lots of tools for locking and controlling access. 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 a runnable example using Rust's "play" server: http://is.gd/bQOY3o http://is.gd/bQOY3o 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. Anyway, is this what you were thinking about? Or did you mean something else?

by ekidd 12y ago

p0nce 12y ago

> 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).

bjz_ 12y ago
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.
- p0nce 12y ago
  Exciting! It will be interesting to see if duck-typing prove more useful or not in the Rust meta world, language wars aside.

Matthias247 12y ago

Regarding the futures: 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.

ekidd 12y ago
Interfaces can sometimes be tricky, especially if you're also working with lifetimes, because there's no way to write "T<'a>" for a generic type. There are are few other gotchas like this. Some of these will get better once associated types land. But yeah, trying to simultaneously manage interfaces, lifetimes and callbacks sometimes requires serious Rust knowledge—and at least for now, you may run into hard barriers. You need some mutable objects (like socket or the object that contains socket) locally AND you need access to them in your continuation. If you're planning on writing to objects from inside a continuation, while you also write to them from your main code as well, you're going to have to think things through pretty carefully in any language, or else the two writers will stomp on each other. Rust has lots of tools for locking and controlling access. 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 a runnable example using Rust's "play" server: http://is.gd/bQOY3o http://is.gd/bQOY3o 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. Anyway, is this what you were thinking about? Or did you mean something else?