5 ms·

These biased bashes against C++ that advertise rust get somewhere between boring and annoying recently. Yes, Rust has some interesting safety features that prev

These biased bashes against C++ that advertise rust get somewhere between boring and annoying recently. Yes, Rust has some interesting safety features that prevent some issues that you can run into with C++ (but not all). And yes, most of us will agree that header files suck and the rust approach here is nicer. That template error message are also PITA is also well known - but on the other hand templates are different (and more powerful) than generics. On the other hand there are still a few constructs that I'm using using often enough in C++ that have currently no sane representation in Rust and that are astonishingly never mentioned in these articles: - Everything that you use the friend keyword for. In Rust there is no way to access private data defined in other file (because that will automatically be another module which is also something I disagree with). - Most things related to inheritance and interfaces. Composition is not always a better solution and Rusts traits seem still more suited for compile-time polymorphism than to runtime polymorphism. As an example try to find the equivalent of a `shared_ptr<SomeThing> thing(new SomeThing()); shared_ptr<ISomeThing> iface = thing` in Rust. And yes, I want to be able to use both afterwards. - Enabling concurrency. Some people might disagree but I think Rust is currently mostly good at preventing multithreading issues - but not at providing good and easy ways to enable it. 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). For some things using low-level primitives like channels (aka queues) and creating new threads might be fine, but there are also enough cases where you would prefer a simple singlethreaded eventloop. All in all I think there are still enough areas where I think Rust still is (unfortunatly) no real alternative for C++. And as long as that's the case I think writing such biased articles isn't fair.

keeperofdakeys 12y ago
Just on your last point, Rust does have the ability to do unsafe code (and many multi-threading primitives use these internally). The real question is, how can these be exposed to Rust in a way that plays nicely with other Rust code. There are things like RefCell, which enables multiple threads to hold a reference to an object, with run-time checking of borrows. Or there are also explicit mutex wrappers that can be used. You could use these with channels, closures, or a callback system. As Rust matures, we should see more of these kinds of features find themselves into the standard library.
- tomjakubowski 12y ago
  There are things like RefCell, which enables multiple threads to hold a reference to an object, with run-time checking of borrows. RefCells do not allow multiple threads to hold a reference to an object because they are not Sync. They only permit dynamic enforcement of Rust's borrowing rules for references, through "interior mutability", as you said.
- Matthias247 12y ago
  The real question is, how can these be exposed to Rust in a way that plays nicely with other Rust code. Yes, that's exactly the question I'm asking myself. I know that you can do everything in unsafe, but as soon as I step into that mode I'm getting the feeling that it might end up in the same level as C++ or probably even more complicated. It probably shouldn't have to do with dealing explicitly with mutexes. If you have to I think that things like std::sync::Mutex are no good solutions because they are not really general purpose. If you really deal with low-level multithreading problems you often have multiple mutexes that might need to be locked in a special order and the mutexes are normally part of a data structure and do not own the data. But multithreading is only a part of the whole problem. The other one is achieving easy-to-use and safe concurrency in a single thread (like Javascript APIs).
  - deleted 12y ago
    [deleted]
Kilgort 12y ago
shared_ptr<SomeThing> thing(new SomeThing()); shared_ptr<ISomeThing> iface = thing Rust is not OOP language, so it's logical that it can't do this. Rust got type system more like Haskell, and for me it's a big plus as I don't like C++ OOP that was taken from Simula and not even from SmallTalk. I don't like talking like this, but C++ OOP is complete trash(beat me for talking like this). Also you are saying that Rust is not alternative for C++ in some ways trying to find what Rust don't have that C++ have. Those languages are completely different conceptually, but they target the same level. Rust is good alternative for C++ even now, taking for consideration that it's not stable(1.0 version will be soon, but it's not there yet). There is no areas where Rust is no alternative for C++, because you can tackle any low-level problem with it, that you can tackle with C++. I don't want to say what language better, because it's not the best comparison. For now, all I can say that Rust is more sense full and more conceptually accurate, it's syntax is more concise and easier to understand than syntax of monstrous language like C++. For the first in the long time we can say that we got low-level language with ability to write code using high-level abstractions and it will be effective. We don't need to drop code understanding for low level optimizations, yet we have power to fully optimize bottlenecks. It's not silver bullet for sure, but guys did a big job here, showing that low level language can be more clear for human.
- humanrebar 12y ago
  > shared_ptr<SomeThing> thing(new SomeThing()); shared_ptr<ISomeThing> iface = thing Not sure what you're trying to do there, but Rust can certainly alias one object with more than one trait reference. In this particular case, you're using two mutable references to the same object, which Rust doesn't allow. But if both were immutable references, there wouldn't be an issue, assuming the right declarations preceded your code.
  - Matthias247 12y ago
    It was my example, so I try to explain it a little more: There are quite a lot of cases where you would like to have things like this, but the example that's probably most straightfoward to understand is GUI systems: E.g. you have a generic `Widget`, the `IWidget`. Then you have some base-class `Container` which contains multiple other widgets (`list<IWidget>`). This might contain a reference to a `TextBox` (which is an implementation of `IWidget`) and another widget (or controller or whatever) might contain also a reference to the same thing. Both might need to be mutable. And in exact that moment you have code like the described one. That's no borderline usecase, it's a thing that you in all popular HMI frameworks (and in C, C++, C#, Java, ...). Maybe you can solve the issues in a completly different fashion, with resorting to only immutable objects (like some approaches for ClojureScript). But these are then no longer zero-cost abstractions versus current technology and they are not that easy to pick up for most mainstream programmers (which expect C++ alternative and not a Haskell alternative). Besides that people are already asking for bindings to things like QT - and that will require similar constructs.
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.
gnuvince 12y ago
Three questions: 1. what is the technical difference between template and generics? 2. how do we know that what Rust has are generics? 3. considering that the Rust type system was recently demonstrated to be Turing-complete, how can it be less powerful than C++'s?
- Matthias247 12y ago
  I'm not the person who can give an exact definition, but imho generics are more related to the type system (you can have types that refer to other types) whereas C++ templates can produce more or less arbitrary code. E.g. the field of template metaprogramming in C++ is not possible with generics. I'm personally not convinced that the extra possiblities and extra complexity of C++ templates vs. a good generics implementation in other languages is worth it, but I just wanted to highlight that the comparison is not fair. And hopefully we will get better error messages with C++ concepts, which will probably compare better to Rusts generics and kinds.
  - chadzawistowski 12y ago
    Tangential, but I'd like to point out that you can achieve compile-time metaprogramming much more easily in D, which provides the entire language during compilation [1]. I find this to be much more straightforward than arcane uses of templates such as SFINAE [2]. [1] http://en.wikipedia.org/wiki/Compile_time_function_execution#example http://en.wikipedia.org/wiki/Compile_time_function_execution... [2] http://en.m.wikipedia.org/wiki/Substitution_failure_is_not_an_error http://en.m.wikipedia.org/wiki/Substitution_failure_is_not_a...

keeperofdakeys 12y ago

Just on your last point, Rust does have the ability to do unsafe code (and many multi-threading primitives use these internally). The real question is, how can these be exposed to Rust in a way that plays nicely with other Rust code. There are things like RefCell, which enables multiple threads to hold a reference to an object, with run-time checking of borrows. Or there are also explicit mutex wrappers that can be used. You could use these with channels, closures, or a callback system. As Rust matures, we should see more of these kinds of features find themselves into the standard library.

tomjakubowski 12y ago
There are things like RefCell, which enables multiple threads to hold a reference to an object, with run-time checking of borrows. RefCells do not allow multiple threads to hold a reference to an object because they are not Sync. They only permit dynamic enforcement of Rust's borrowing rules for references, through "interior mutability", as you said.
Matthias247 12y ago
The real question is, how can these be exposed to Rust in a way that plays nicely with other Rust code. Yes, that's exactly the question I'm asking myself. I know that you can do everything in unsafe, but as soon as I step into that mode I'm getting the feeling that it might end up in the same level as C++ or probably even more complicated. It probably shouldn't have to do with dealing explicitly with mutexes. If you have to I think that things like std::sync::Mutex are no good solutions because they are not really general purpose. If you really deal with low-level multithreading problems you often have multiple mutexes that might need to be locked in a special order and the mutexes are normally part of a data structure and do not own the data. But multithreading is only a part of the whole problem. The other one is achieving easy-to-use and safe concurrency in a single thread (like Javascript APIs).
- deleted 12y ago
  [deleted]

Kilgort 12y ago

shared_ptr<SomeThing> thing(new SomeThing()); shared_ptr<ISomeThing> iface = thing Rust is not OOP language, so it's logical that it can't do this. Rust got type system more like Haskell, and for me it's a big plus as I don't like C++ OOP that was taken from Simula and not even from SmallTalk. I don't like talking like this, but C++ OOP is complete trash(beat me for talking like this). Also you are saying that Rust is not alternative for C++ in some ways trying to find what Rust don't have that C++ have. Those languages are completely different conceptually, but they target the same level. Rust is good alternative for C++ even now, taking for consideration that it's not stable(1.0 version will be soon, but it's not there yet). There is no areas where Rust is no alternative for C++, because you can tackle any low-level problem with it, that you can tackle with C++. I don't want to say what language better, because it's not the best comparison. For now, all I can say that Rust is more sense full and more conceptually accurate, it's syntax is more concise and easier to understand than syntax of monstrous language like C++. For the first in the long time we can say that we got low-level language with ability to write code using high-level abstractions and it will be effective. We don't need to drop code understanding for low level optimizations, yet we have power to fully optimize bottlenecks. It's not silver bullet for sure, but guys did a big job here, showing that low level language can be more clear for human.

humanrebar 12y ago
> shared_ptr<SomeThing> thing(new SomeThing()); shared_ptr<ISomeThing> iface = thing Not sure what you're trying to do there, but Rust can certainly alias one object with more than one trait reference. In this particular case, you're using two mutable references to the same object, which Rust doesn't allow. But if both were immutable references, there wouldn't be an issue, assuming the right declarations preceded your code.
- Matthias247 12y ago
  It was my example, so I try to explain it a little more: There are quite a lot of cases where you would like to have things like this, but the example that's probably most straightfoward to understand is GUI systems: E.g. you have a generic `Widget`, the `IWidget`. Then you have some base-class `Container` which contains multiple other widgets (`list<IWidget>`). This might contain a reference to a `TextBox` (which is an implementation of `IWidget`) and another widget (or controller or whatever) might contain also a reference to the same thing. Both might need to be mutable. And in exact that moment you have code like the described one. That's no borderline usecase, it's a thing that you in all popular HMI frameworks (and in C, C++, C#, Java, ...). Maybe you can solve the issues in a completly different fashion, with resorting to only immutable objects (like some approaches for ClojureScript). But these are then no longer zero-cost abstractions versus current technology and they are not that easy to pick up for most mainstream programmers (which expect C++ alternative and not a Haskell alternative). Besides that people are already asking for bindings to things like QT - and that will require similar constructs.

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.

gnuvince 12y ago

Three questions: 1. what is the technical difference between template and generics? 2. how do we know that what Rust has are generics? 3. considering that the Rust type system was recently demonstrated to be Turing-complete, how can it be less powerful than C++'s?

Matthias247 12y ago
I'm not the person who can give an exact definition, but imho generics are more related to the type system (you can have types that refer to other types) whereas C++ templates can produce more or less arbitrary code. E.g. the field of template metaprogramming in C++ is not possible with generics. I'm personally not convinced that the extra possiblities and extra complexity of C++ templates vs. a good generics implementation in other languages is worth it, but I just wanted to highlight that the comparison is not fair. And hopefully we will get better error messages with C++ concepts, which will probably compare better to Rusts generics and kinds.
- chadzawistowski 12y ago
  Tangential, but I'd like to point out that you can achieve compile-time metaprogramming much more easily in D, which provides the entire language during compilation [1]. I find this to be much more straightforward than arcane uses of templates such as SFINAE [2]. [1] http://en.wikipedia.org/wiki/Compile_time_function_execution#example http://en.wikipedia.org/wiki/Compile_time_function_execution... [2] http://en.m.wikipedia.org/wiki/Substitution_failure_is_not_an_error http://en.m.wikipedia.org/wiki/Substitution_failure_is_not_a...