Live data from Hacker News

Rust for C++ programmers – part 4: unique pointers

featherweightmusings.blogspot.com

1–10 of 99 posts

Re: Rust for C++ programmers – part 4: unique pointers

#4
Rust looks very exciting and promising. I see the hardest things for it to be not necessarily syntax and concurrency (which are very well done), but performance and getting to compete with C++11 (C++14), which actually seems to become fresh and interesting again.

Performance is tough. I feel most often C++ is not chosen for its inherent cleanliness, elegance and beauty, but because there are no viable competitors at the given performance point. C++ compilers have been honed and tweaked for more than a decade now, so it will be a hard battle ahead.

Re: Rust for C++ programmers – part 4: unique pointers

#5
post #4

Rust looks very exciting and promising. I see the hardest things for it to be not necessarily syntax and concurrency (which are very well done), but performance and getting to compete with C++11 (C++14), which actually seems to become fresh and interesting again. Performance is tough. I feel most often C++ is not chosen for its inherent cleanliness, elegance and beauty, but because there are no viable competitors at…

I feel pretty good about it. For one, we have significantly better aliasing information than C++, and we use most of the guts, including all the optimizations and code generation, of a C++ compiler (clang/LLVM). There are also some optimizations around move semantics that are open to us but not for C++ as standardized.

That said, there are definitely performance bugs that have yet to be fixed. But I would definitely say most Rust code, if well-written, can be competitive with C++ today.

Re: Rust for C++ programmers – part 4: unique pointers

#6
post #4

Rust looks very exciting and promising. I see the hardest things for it to be not necessarily syntax and concurrency (which are very well done), but performance and getting to compete with C++11 (C++14), which actually seems to become fresh and interesting again. Performance is tough. I feel most often C++ is not chosen for its inherent cleanliness, elegance and beauty, but because there are no viable competitors at…

> Performance is tough. I feel most often C++ is not chosen for its inherent cleanliness, elegance and beauty, but because there are no viable competitors at the given performance point.

I don't think there are many popular high level languages that target systems programming in the first place.

Re: Rust for C++ programmers – part 4: unique pointers

#7

>>The memory will not leak however, eventually it must go out of scope and then it will be free. Yes, if the function that called it lives for ever the point is perhaps moot, in an extreme case if it was called by 'main'.

If the pointer is returned all the way up to the main function, then it must be required for the lifetime of the program (or else the program is poorly designed). What point are you trying to make?

Re: Rust for C++ programmers – part 4: unique pointers

#8
I've been working C++ professionally for a couple of years and honestly I'm a huge fan - So I was excited to read about an alternative. After reading your 5 posts, I get the impression that RUST is mostly mildly useful syntactic sugar on top of C++.

Here is my feedback:

1 - If memory management is a serious problem for the software you work on, I've never found the boost library lacking. This seems like the main selling point for RUST. Given the scope of the project: you guys must be doing something that is so different that it couldn't be rolled into a library - so I'm looking forward to your future posts to see if there is something here that I really am missing out on.

2 - I'm not a fan of the implicitness and I personally don't use 'auto' b/c it makes scanning code harder. I guess this is more of a personal preference.

3 - A lot of things are renamed. auto->let, new->box, switch->box You get the feeling that effort was put in to make the language explicitly look different from C++

4 - the Rust switch statement don't fall through... This one was truly mind blowing. The one useful feature of switch statement got ripped it out! If you don't really need the fall through, I'd just avoid using them completely...

5 - I've never really seen an equivalent to boost (in combination to the STL) in other languages (maybe I didn't look hard enough). Could you maybe make a post about the RUST standard library? Libraries are always the deal breaker

To that point, my last comment is maybe a little more wishy washy. The main reason I'm consistently happy with using C++ (and why I put up with the header files) is that everything is available. If you need to do X, and X has at some point been put into library by someone: you can be sure that that library will be available in C++. Since Rust seems so close to C++, does this mean that linking to C++ code is trivial? If I can seamlessly start programming parts of our codebase in RUST, that could potentially make a huge impact.

Re: Rust for C++ programmers – part 4: unique pointers

#9

I've been working C++ professionally for a couple of years and honestly I'm a huge fan - So I was excited to read about an alternative. After reading your 5 posts, I get the impression that RUST is mostly mildly useful syntactic sugar on top of C++. Here is my feedback: 1 - If memory management is a serious problem for the software you work on, I've never found the boost library lacking. This seems like the main sell…

The 'let' keyword introduces a variable. It's not 'auto'.

You can still declare variables types explicitly: 'let x: int = 5'

'match' is also much more powerful than 'switch'. You can match on several patterns, ranges of numbers, as well as use guards.

http://rustbyexample.com/examples/match/README.html

Re: Rust for C++ programmers – part 4: unique pointers

#10

I've been working C++ professionally for a couple of years and honestly I'm a huge fan - So I was excited to read about an alternative. After reading your 5 posts, I get the impression that RUST is mostly mildly useful syntactic sugar on top of C++. Here is my feedback: 1 - If memory management is a serious problem for the software you work on, I've never found the boost library lacking. This seems like the main sell…

>1 - If memory management is a serious problem for the software you work on, I've never found the boost library lacking. This seems like the main selling point for RUST. Given the scope of the project: you guys must be doing something that is so different that it couldn't be rolled into a library - so I'm looking forward to your future posts to see if there is something here that I really am missing out on.

I would say that Rust's defining feature is the borrow checker[1], which eliminates an entire category of pointer related errors at compile time.

>3 - A lot of things are renamed. auto->let, new->box, switch->box You get the feeling that effort was put in to make the language explicitly look different from C++

Rust is strongly influenced by the ML family of languages. I believe that's where some of the keywords came from.

>4 - the Rust switch statement don't fall through... This one was truly mind blowing. The one useful feature of switch statement got ripped it out! If you don't really need the fall through, I'd just avoid using them completely...

Rust doesn't have a classical switch statement. Instead, it has a 'match' keyword that performs pattern matching on the input so you can easily destructure a complicated blob of data into more manageable pieces. This is also a concept borrowed from the ML family. If you really wanted to, you could write a macro that emulates the C style switch statement.

>5 - I've never really seen an equivalent to boost (in combination to the STL) in other languages (maybe I didn't look hard enough). Could you maybe make a post about the RUST standard library? Libraries are always the deal breaker

There's a great overview[2] of what the standard distribution contains on the Rust website.

[1] http://static.rust-lang.org/doc/master/rustc/middle/borrowck...

[2] http://static.rust-lang.org/doc/master/index.html#libraries

Post reply on HN