[bambam12897]

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.

[comex]

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

https://github.com/crabtw/rust-bindgen

[bambam12897]

Thanks for taking the time to address my questions. Memory management hasn't been a major stumbling block in my line of work, but I'll read up and give it a whirl if I have the appropriate project.

[ahy1]

> Most C++ code uses switch frequently, usually without taking advantage of fallthrough.

I am not so sure about this. Thinking back on my uses of switch in C and C++, I am not able to remember using switch without taking advantage of fallthrough. Maybe I am just not a typical C++ programmer...

[jcmoyer]

>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

[mercurial]

I'll add that Rust's match statement, as far as I can see, is more powerful than what Haskell offers: it combines pattern matching and guards, and lets you match different pattern with the same block (the patterns should bind the same variables and they should have the same type, obviously).

[bambam12897]

Looks like I have a lot to read up on. Thank you for pointing me in the right direction.

[masklinn]

> 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

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<int>) in the first place. This also works for structs, the caller can decide where he wants the return value allocated.

[loup-vaillant]

If I had to guess, I'd say "box" is a reference to "boxed values" mentioned in many papers about functional language compilation. Typically, the stack of these implementation would either be "unboxed values", or pointers to "boxes" on the heap.

Clearly, some of those folks have worked on ML or Haskell implementations.

[bad_user]

> If memory management is a serious problem for the software you work on, I've never found the boost library lacking.

As a developer that isn't working with C++, I'm finding memory management in C++ to be a nightmare and no amount of libraries can solve it.

Say you receive a pointer from somewhere. Is the referenced value allocated on the stack or on the heap? If allocated on the heap, do you need to free it yourself, or is it managed by whatever factory passed it to you? If you need to deallocate that value, is it safe doing so? Maybe another thread is using it right now. If you received it, but it should get deallocated by the factory that gave it to you, then how will the factory know that your copy is no longer in use? Maybe it's automatic, maybe you need to call some method, the only way to know is to read the docs or source-code very carefully for every third-party piece of code you interact with.

All of this is context that you have to keep in your head for everything you do. No matter how good you are, not matter how sane your practices are, it's easy to make accidental mistakes. I just reissued my SSL certificate, thanks to C++.

Yeah, for your own code you can use RAII, smart pointers, whatever is in boost these days and have consistent rules and policies for how allocation/deallocation happens. Yay! Still a nightmare.

Even if manageable, there's a general rule of thumb that if a C++ project doesn't have multiple conflicting ways of dealing with memory management and multiple String classes, then it's not mature enough.

[nly]

> Say you receive a pointer from somewhere.

Here's your problem. In general I don't want to be receiving a single pointer from anyone. Lately, I've found it helpful to think of pointers in C++ as special iterators rather than a referential relic from C. In such a mindset passing pointers around without an accompanying end iterator, or iteration count, just makes no sense. Anywhere that implied iteration count is always a constant, I'm probably not structuring my code correctly.

So my recommendation is to use references (foo&) for passing down (well, up) the stack, never to heap allocated objects. Because you can't use delete on a reference there's no longer an ambiguity. Use smart pointers to manage the heap. Write RAII wrappers (it's not a lot of code) to manage external resources. RAII wrappers are especially useful for encapsulating smart pointers so big things can be passed around with value semantics, which gives you even stronger ability to reason. Implementing optimisations like copy-on-write becomes fairly trivial.

> I just reissued my SSL certificate, thanks to C++.

If you're referring to Heartbleed then OpenSSL is written in C, not C++. Generally only a language that inserts array bounds checks for every access would have shielded you from this bug... C++s <vector> does this if you use the at() function of <vector>, but op[] doesn't by default for performance reasons.

[roel_v]

As a developer that isn't working with C++, I'm finding memory management in C++ to be a nightmare

?

[berkut]

I've never had an issue with memory management in C / C++ (and I've had experience of writing C#/Java in enterprise applications, so I know what not having to do it is like).

There is an overhead to having to think and plan for it, but in my experience of using it for things ranging from realtime systems through to high performance, multi-threaded image processing and rendering applications, at least if you're in control of most of the code and it's pretty good code, it's not really an issue.

[loup-vaillant]

> if a C++ project doesn't have multiple conflicting ways of dealing with memory management and multiple String classes, then it's not mature enough.

Hmm… How can I tell maturity from rot?

[pcwalton]

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

When use-after-free becomes a security concern that commonly leads to remote code execution, as it is for us in the browser space, it becomes very apparent just how inadequate modern C++ is at the task. Everything works fine, the tests pass, people use it in production, and yet all the time someone discovers some way to make the stars align to produce a use-after-free bug. This has happened over and over again, despite all the smart pointers and modern C++ techniques.

The fact is that modern C++ just isn't memory safe, and after digging deep into the problem to try to solve it with Rust I'm convinced now that it can never be. The language just has too many core features, such as references, iterators, and the "this" pointer, that cannot be made memory safe without sacrificing backwards compatibility.

[coldtea]

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

No, the main selling point is memory management with guarantees for safety but full performance. You don't get that just with boost, it's mostly a GC.

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

Type inference removes redundant information.

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

Huh? The fall-through has been known to be a bug hazard and bad style for ages. And for what, to save a few lines with a not that clever trick? The only useful abuse of the Switch was Duff's device, and that's stretching it already.

[pix64]

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

[ben0x539]

Features-wise, C++ probably subsumes a lot of languages, so from a certain perspective, everything else looks like a weird syntax for a subset of C++.

And it's true that Rust is edging closer and closer to C++ in some ways. It certainly didn't start there, old ("old", 2010 or so) Rust looks pretty weird with lots of esoteric features (effects! structural types!) and built-in magic. Over time Rust probably ~focused on its core values~ etc, which resemble that of C++, and also grew more powerful as a language so that most things can now live in the library rather than in the compiler, which is I guess something that C++ also prides itself with.

But more seriously, the whole motivation for Rust isn't what features it gives, but what it takes away. All the traits and algebraic datatypes and type inference and other shiny Rust features, if someone walked up to the Rust people with an implementation of that as a source filter for C++ or whatever, it still wouldn't sell. The mission of Rust (as I see it, from the distance) isn't to make a more convenient or powerful C++, it's to make a language convenient and powerful enough that people won't miss C++'s laissez-faire attitude towards memory safety.

To that effect, Rust isn't really aiming to compete with C++ on a feature-for-feature basis, but it has to include features that enable a style of programming that is competitive with C++ performance and convenience without relying on memory-unsafe features.

(I guess the `unsafe { }` sub-language comes off as an admission that that won't work, but it's arguably just a way to introduce new safe primitives that requires particularly careful manual checking, just like adding features to the language that the compiler assumes are safe, and anyway it's mostly equivalent to linking to arbitrary C code without which the language would pretty much be a non-starter anyway.)

[rat87]

Warning these are just my impressions, I haven't fully tried out rust.

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

Generally every non-trivial program has bugs(possibly excluding tex which was written by one of the greatest computer scientists of all time and after years of being open with bragging rights for anyone who finds a bug, but I'm not even sure about it). Rust aims to reduce bugs including memory bugs as much as possible with static typing. It's probably the language that most concentrates on preventing bugs with static typing/analysis this side of haskell. Even if c++ could have some similar feature if some library used carefully this is not the same as people could still abuse unsafe features not allowed in rust outside of unsafe blacks.

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

It is a matter of style but as someone who puts var in front of everything but basic types in c# I think its a good default. An ide can help a lot by showing type on hover.

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

Although rust is somewhat influenced by C++ aiming to take over its problem domain it is probably more influenced by functional languages like Ocaml. let comes from ocaml, match instead of switch also comes from ocaml(note that match is more powerful then switch). Also note that let isn't exactly the same as auto, let allows declaring local variables, rust default to implicit typing for local variables but you can specify them and it will still have let. ex.

    let monster_size: int = 50;

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

There aren't that many useful switch statements that fallthrough for reasons other then matching multiple values to one execution path and rust allows you to match one of a number of values or in a containing range. ex.

    match my_number {
      0     => println!("zero"),
      1 | 2 => println!("one or two"),
      3..10 => println!("three to ten"),
      _     => println!("something else")
    }

There are some other uses for switch fall through such as duffs device(cool but hard to understand and not necessarily a speed up these days) and things like http://programmers.stackexchange.com/a/116232 where some cases include other cases(not that common, can be simulated with if/else's). Fallthorugh is a confusing "feature" which can lead to bugs if you forget to put break which goes against the rust philosophy and it would be even more confusing when using the return value of match.(note I'm think this next example is right)

    println!("my number is {}!", match my_number {
      0     => println!("zero"),
      1 | 2 => println!("one or two"),
      3..10 => println!("three to ten"),
      _     => println!("something else")
    }

In rust matches and if/else statemnts are expressions. This gives you a nice looking ternary expression. And makes some functions shorter.

I think that if there are multiple ';' seperated expressions in an if/else or => result wrapped with {} it will return the last expression if it isn't followed by a ; otherwise it returns unit(a type meaning something similar to void). But I could be wrong.

> 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

The equivalent of Boost in what way? Boost is a collection of many(>80) different libraries some of which (ab)use the language in very interesting ways. Some of these eventually move into the standard and stdlib. I don't think any other languages have this sort of feeder collection. That said many languages have officially or unofficially blessed libraries which sometimes make it to the stdlib. Rust is fairly young and a moving target so there aren't many 3rd party libraries yet but hopefully that will change once it stabilizes and the package manager is mature.

[Dewie]

> 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 inspired by more languages than just C++, believe it or not. :)