Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparing Rust and C++

kukuruku.co

Post reply on HN
Print view View original

81–90 of 139 posts

Re: Comparing Rust and C++

#81

Post by p0nce »

bjz_ wrote: post #63
p0nce wrote: post #47

Earlier quoted context omitted.

> 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…

Exciting! It will be interesting to see if duck-typing prove more useful or not in the Rust meta world, language wars aside.

Re: Comparing Rust and C++

#82

Post by Matthias247 »

humanrebar wrote: post #67
Kilgort wrote: post #41

Earlier quoted context omitted.

shared_ptr thing(new SomeThing()); shared_ptr 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…

> shared_ptr thing(new SomeThing()); shared_ptr 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.

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

Re: Comparing Rust and C++

#83

Post by [deleted] »

tomjakubowski wrote: post #78
mike-cardwell wrote: post #71

Earlier quoted context omitted.

Here is some example code showing the problem: http://pastebin.com/6wu7bcrF I compiled it using both: g++ -std=c++14 -Wall -Wextra -g test.cpp -o test clang++ -std=c++14 -Wall -Wextra -g test.cpp -o test GCC v4.9.1 and Clang v3.5.0. Under neither case did it supply any warnings at compile time. In both cases it segfaults when it hits the second std::cout whilst running.

Since that's undefined behavior anything (including and especially things worse than a segmentation fault) could happen.

[deleted]

Re: Comparing Rust and C++

#84

Post by humanrebar »

lmm wrote: post #66
frozenport wrote: post #28

Earlier quoted context omitted.

Not only legacy, many hardware vendors provide only C bindings leaving the management of resources to the user.

How many hardware vendors provide any kind of Rust bindings at all? Let's compare like with like.

Maybe a more fair example would be std::fstream from C++, which takes a `char const ` (no size integer) or a `std::string` (a.k.a. string buffer) as constructor arguments. In the most idiomatic C++ possible, the standard library would support two character iterators.

In Rust, the equivalent might be:

  let ioResult = File::open(&Path::new("foo.txt"));
...no unsafe pointers or mandatory allocation necessary (1). Plus you're forced to check your error condition by unwrapping the returned value.

I don't bring that up to pick a nit, but to point out that this is basically the state-of-the-art (well, the char might be paired with a size_t) for passing strings through C++ APIs.

(1) I'm not sure whether Path::new actually allocates, but there's nothing stopping you from implementing a tight-and-fast InPlacePath that works seamlessly.

Re: Comparing Rust and C++

#85

Post by wfunction »

adrusi wrote: post #23
wfunction wrote: post #13

How does Rust handle multiple object files and dynamic linking? It seems to me that pretty much all of these guarantees break down if the compiler can't see the source code for the whole program at once.

All the information needed to make these guarantees is the type information of all visible items in a translation unit ("crate").

I'm skeptical. Did they really make the type information stored in the ABI that advanced? Storing that kind of information outside of name mangling is a nontrivial feat (i.e. they'd need to rewrite the linker) and there's not a whole lot of information you can pack into name mangling.

Re: Comparing Rust and C++

#86

Post by [deleted] »

Matthias247 wrote: post #69
keeperofdakeys wrote: post #40

Earlier quoted context omitted.

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 u…

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…

[deleted]

Re: Comparing Rust and C++

#87

Post by humanrebar »

Matthias247 wrote: post #82
humanrebar wrote: post #67

Earlier quoted context omitted.

> shared_ptr thing(new SomeThing()); shared_ptr 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.

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 `). This might contain a reference to a `TextBox` (which is an impl…

I'm not aware of any production quality UI toolkits in Rust, but using traits and reference counting, Rust certainly supports this use case.

In fact, it supports it more flexibly since different widgets don't have to share the same methods and data at all... well, unless you want them to. And you can have your widgets implement more than one trait without having to combine them all into one giant class definition.

Re: Comparing Rust and C++

#88

Post by Dewie »

kbart wrote: post #80
iopq wrote: post #22

Earlier quoted context omitted.

It's not meant to be fair. Rust is created as a successor of C++ to completely overtake it everywhere.

If I only get a penny every time I hear this "C++ is dead, the is going to replace it everywhere"..

The proposition is so far-fetched that I suspected that he was being facetious.

Re: Comparing Rust and C++

#89

Post by humanrebar »

moomin wrote: post #58

I'd actually much rather read the opposite article: things that C++ excels at that Rust falls down on. I'm not an expert, but I think there's still allocation use cases C++ is better at.

Off the top of my head:

* C++ has more robust compile-time meta-programming facilities, at least for the time being.

* C++ can generally include C (well, C89) code as-is with no translation layer. Rust's FFI is pretty inoffensive, but it's more work than a #include

* It's easier to do the really dangerous stuff if you have a good reason to. You can actually call push_back on a std::vector without invalidating your iterators if you're careful. I've never seen it used properly in production code, but it's possible. At any rate, it might be more awkward to write equivalent code in Rust. Then again, maybe a deque is better than a vector for this use case, in which case I suspect that Rust is capable of a more optimal solution than push_back or std::back_inserter.

Re: Comparing Rust and C++

#90

Post by kibwen »

Dewie wrote: post #79
kibwen wrote: post #68

I've flagged this because not only is it an unfair characterization of C++, it's also using a version of Rust that is six months out of date. As a Rust fan, I don't think we need to resort to cheap shots. The language stands well enough on its own; misinformation and propaganda pieces won't get us anywhere.

If anything, the Rust community seems more concerned with only showing the good sides of its community than it is with only showing the good sides of Rust. That of course has its social/"political" advantages.

I see this as a technical advantage, not a political one. I want the language to be legitimately great, which means that we need to encourage an atmosphere where people feel welcome to express informed and constructive criticism. Breathless praise is surely kind, but it doesn't really advance the conversation. In other words: I already know that the language is good; I want you to tell me how it could be better.
Post reply on HN