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

41–50 of 139 posts

Re: Comparing Rust and C++

#41

Post by Kilgort »

Matthias247 wrote: post #36

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

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

Re: Comparing Rust and C++

#42

Post by ekidd »

Matthias247 wrote: post #36

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

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

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.

Re: Comparing Rust and C++

#43

Post by andywood »

TillE wrote: post #5
shmerl wrote: post #3

Raw pointers is a bad example to compare to Rust. It's more like comparing C to it. If anything one should compare managed pointers like std::shared_ptr and etc, especially since the author mentions C++11.

Also failed to use std::thread and its related synchronization primitives. And nobody who's been writing C or C++ for more than five minutes would actually make that mistake with a switch statement (omitting breaks). On the contrary, its fall-through behavior is often very convenient.

I have to agree with you. It's never registered as a problem for me. I think of it like an ordinary kitchen knife. Yeah there's an off chance I might cut myself, but 99% of the time I'm just going to enjoy a steak.

Re: Comparing Rust and C++

#44

Post by JulianMorrison »

claudius wrote: post #6

It might be a good idea to compare C++ and Rust and not “C with Classes and no use of compiler options” and Rust. They do have a fair point about ugly template error messages, but the remaining issues are mostly moot: Freed memory issues can be avoided using std::unique_ptr and its siblings, lost pointers to local variables shouldn’t occur when using references instead of pointers, uninitialised variables are warned…

C++ is like a fairytale forest, where staying on the one safe path through the woods (unmarked, known only by whispered lore) will give you a reliable system, but where you are constantly tempted by easier-looking diversions at the end of which lurk grues.

And heaven help you if nobody has yet whispered to you the secret of the one safe path. Or if you consulted an older textbook, and the idiom it taught has a grue.

Re: Comparing Rust and C++

#45

Post by pjmlp »

gilgoomesh wrote: post #15
claudius wrote: post #6

It might be a good idea to compare C++ and Rust and not “C with Classes and no use of compiler options” and Rust. They do have a fair point about ugly template error messages, but the remaining issues are mostly moot: Freed memory issues can be avoided using std::unique_ptr and its siblings, lost pointers to local variables shouldn’t occur when using references instead of pointers, uninitialised variables are warned…

> Freed memory issues can be avoided using std::unique_ptr and its siblings You can use a std::unique_ptr after it is assigned to something else. That's basically a use after free. > lost pointers to local variables shouldn’t occur when using references instead of pointers Lost references to heap variables happen all the time in C++ when the target is deallocated before the reference is accessed. It's the same proble…

> You can use a std::unique_ptr after it is assigned to something else. That's basically a use after free.

While true, you can make it throw in such scenarios.

I wouldn't be surprised if the debug builds of modern C++ compilers wouldn't do it already.

Re: Comparing Rust and C++

#46

Post by pjmlp »

anon1385 wrote: post #11
claudius wrote: post #6

It might be a good idea to compare C++ and Rust and not “C with Classes and no use of compiler options” and Rust. They do have a fair point about ugly template error messages, but the remaining issues are mostly moot: Freed memory issues can be avoided using std::unique_ptr and its siblings, lost pointers to local variables shouldn’t occur when using references instead of pointers, uninitialised variables are warned…

>uninitialised variables are warned against when compiling with the (hopefully standard) -Wall -Werror Not with GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55873 Obviously it should warn you, but when one of the most popular C++ compilers has been failing to report uninitialised variables for 10 years then I think that the issue is worth raising. Clearly signif…

> Clearly significant sections of the C++ community don't place a high value on the accuracy of these kinds of compiler warnings.

This comes from the inherited C culture. After all lint was developed alongside the C compiler (in 1979).

How many C developers care to use static analysis?

Re: Comparing Rust and C++

#47

Post by p0nce »

ekidd wrote: post #42
Matthias247 wrote: post #36

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

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…

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

Re: Comparing Rust and C++

#48

Post by tomjakubowski »

keeperofdakeys wrote: post #40
Matthias247 wrote: post #36

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

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…

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.

Re: Comparing Rust and C++

#49

Post by swah »

seabee wrote: post #4
shin_lao wrote: post #2

If I understood correctly, it is not possible to manually manage memory in Rust and do things like memory recycling or pools?

No, you can do that, and can do so safely (if you implemented the unsafe parts correctly, at least). For example, here's an arena allocator crate: http://doc.rust-lang.org/arena/

Are those annotations like Java's?

http://doc.rust-lang.org/src/arena/lib.rs.html#353-363

I wish languages would let you say the whole file/module is special - for example, inline all functions.

Re: Comparing Rust and C++

#50

Post by gnuvince »

Matthias247 wrote: post #36

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

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?

Post reply on HN