11–20 of 99 posts
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…
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.
Hopefully the "going back to native" trend will move us back on track, similar to how it happened in the early 80's VM attempts.
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…
A key feature of Rust is being memory safe by default without sacrificing too much performance. In C++ it's not really possible to be completely safe, and pretty much all real-world C++ I've seen doesn't even come close to that ideal, using raw pointers frequently; the result is that crashes can be relatively mysterious and, perhaps more importantly, that in large C++ codebases with lots of attack surface, like browsers, security vulnerabilities are extremely frequent. So yes, memory management is a serious problem.
In particular, there is no way to replicate Rust-style borrowed pointers in C++, which make safe low-level programming easier.
> 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...
Most C++ code uses switch frequently, usually without taking advantage of fallthrough. Rust match is good for this, but it can also be used for more complex things (destructuring); using this frequently makes for code that looks quite different from C++.
> The main reason I'm consistently happy with using C++ (and why I put up with the header files) is that everything is available.
The bad news: as Rust is still a very unstable language, there isn't much of a library ecosystem.
The good news: by release, Rust will have a standard package manager, which should make importing libraries easier than in C and C++ where every package has its own build system. I think Go has been pretty successful with this approach.
> Since Rust seems so close to C++, does this mean that linking to C++ code is trivial?
Nope... I would personally like this feature, although it would be difficult to make reliable because Rust has different semantics in various areas - OOP is very different, templates are (intentionally) not as powerful, etc.
However, you can import C headers using rust-bindgen [1] and fairly easily link to C code.
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…
Rust is inspired by more languages than just C++, believe it or not. :)
>>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?
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. A key feature of Rust is being memory safe by default without sacrificing too much performance. In C++ it's not really possible to be completely safe, and pretty much all real-world C++ I've seen doesn't even come close to that ideal, using raw pointers frequently; the result is that crashes can b…
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 s…
Earlier quoted context omitted.
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?
It could also be a memory leak. For example, I have a for loop that keeps requesting a new pointer...
Earlier quoted context omitted.
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?
It could also be a memory leak. For example, I have a for loop that keeps requesting a new pointer...
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…
Memory safety and static checking.
> 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++
* let comes from ML and similar languages (e.g. Haskell), which are a huge inspiration of Rust (e.g. the type system). Furthermore, let is not auto, it does pattern matching, it's not just a limited form of type inference (or it'd be after the colon, where the type goes).
* match is much the same, it's a pattern-matching construct not just a jump table
* box is for placement box, IIRC it's similar to a universal placement new. For instance it can be used thus:
// looks like it returns a basic stack-allocated value
fn foo() -> int {
3
}
let stack_allocated = foo();
let heap_allocated = box foo();
the second one has no more overhead than if the function had returned `box 3` and a ~int (~unique_ptr) in the first place. This also works for structs, the caller can decide where he wants the return value allocated.