17 ms·

A taste of Rust for C/C++ programmers

155 points by wofo 12y ago

krylon 12y ago
I recently started looking at Rust. I somehow had this idea in my head that it was a weird language, but up close, it is quite a friendly beast. Interesting, though.
- stormbrew 12y ago
  It has gotten a lot friendlier-looking in recent versions, thanks to the reduction in odd type-punctuation for lifetime description. It's more uniform now.
  - cheez 12y ago
    Those attributes that look like comments have to go. Geez.
    - steveklabnik 12y ago
      It's likely that they will turn into @foo rather than #[foo]. The proposal is still being worked on.
      - Argorak 12y ago
        I don't understand the problem. Rust doesn't have # for comments, and I find `#[random]` easier to the eyes then `@random`. Or are we speaking about `@[random]`? Then again, I've never been one for micro-syntax-discussions.
        steveklabnik 12y ago
        The motivation doesn't have to do with it looking like comments: https://github.com/rust-lang/rfcs/pull/386 https://github.com/rust-lang/rfcs/pull/386
        Argorak 12y ago
        Ah, okay, thanks!
      - cheez 12y ago
        Good enough for me.
    - pjmlp 12y ago
      Too much shell programming?
      - dbaupp 12y ago
        A lot of popular non-shell languages use #, e.g. Ruby, Python, PHP.
        pjmlp 12y ago
        Scripting languages, usually coupled with shell programming.
        dbaupp 12y ago
        That's not really a sensible association. A lot of work is done with those languages where shells are either not used at all, or are just a development tool (e.g. could be replaced by editor features). It seems rather strange to try to forcibly connect Python/Ruby/... and sh, rather than just grouping as languages that happen to share the # for comments. (Maybe they adopted it from shells originally, but the languages definitely stand on their own now.)
        pjmlp 12y ago
        I never used them for anything else other than scripts on steroids, as I care for application performance. Well, PHP is forced upon me by my ISP and I never bothered to change.
- kaoD 12y ago
  It is indeed a weird language. I've been rusting heavily for about a week (doing Matasano crypto challenges) and I'm still puzzled at lifetime errors. Managing lifetimes is hard to reason about (though this is not a problem with Rust, but with lifetimes... Rust just makes it explicit.) As soon as you start using generics things can quickly get out of control. Here's one of my function signatures: pub fn xor_together<'a, 'b, 'r, A, B, R, T, U>(iter_a: T, iter_b: U) -> Map<'r, (&'a A, &'b B), R, Zip<T, U>> where A: BitXor<B, R>, T: Iterator<&'a A>, U: Iterator<&'b B> If you get those lifetimes wrong, the error propagates and you end up having lifetime errors farther in your call chain, which are quite hard to debug. I'm not even sure those lifetimes are 100% right. Some other weird things include closures. There are several types of closures, not interchangeable with each other (nor with fn) and honestly I don't understand them (and couldn't find docs to explain them). I hope this changes as Rust stabilizes. I'm loving it so far, but boy... how hard it is.
  - kibwen 12y ago
    Closures are soooo messed up right now, because we're in the process of replacing them wholesale but the new system is only half-implemented. As a result you're forced to choose between using closures that work but suck (the old system) or closures that don't suck but don't work (the new system). So don't judge us on closures just yet. :)
    - MetaCosm 12y ago
      I hope that when Rust hits 1.0 -- they take backward compatibility exceptionally seriously. The pre-1.0 path has been exceptional wild ride, and it has made me a bit gun shy about the language as a whole. I am no stranger to pre-1.0 languages, I have worked with lots of them, but none have been as frustrating (or interesting) as Rust... the question as to will Rust grow into a production language or an academic toy still remains an open one in my book. Reserving judgement until 1.0 is out.
      - steveklabnik 12y ago
        > I hope that when Rust hits 1.0 -- they take backward compatibility exceptionally seriously. We do and we will. It's one of the reason there's such churn right now: we can't keep doing that post 1.0.
amelius 12y ago
The best test of a language is to see if you can write the compiler itself in the language (step 1) and also if you can write the runtime system in that language (step 2). IMHO, both are required for a language to be considered a good "systems language", and a worthy competitor of e.g. C++. I know that the Rust compiler is written in Rust (step 1), but I'm not sure about the runtime.
- dbaupp 12y ago
  Rust is yes to both, although 'the runtime' is disappearing, replaced by just using the system APIs directly (that is, Rust will have no runtime beyond what C/C++ has). The non-Rust code in the main distribution is: - LLVM for the complier - hoedown (markdown parser/renderer) for the documentation generator - miniz for compressing the metadata stored in each library - a few other tiny wrappers[1] for which I see no reason other than inertia/low-priority for translating into Rust (e.g. there would be no particular build-system benefit to Rustifying them because C/C++ compilers are needed for the other things anyway) [1]: https://github.com/rust-lang/rust/tree/master/src/rt https://github.com/rust-lang/rust/tree/master/src/rt (the 'rt' = runtime name is a holdover from when the runtime was not written in Rust)
  - AceJohnny2 12y ago
    > beyond what C/C++ has Whoa now, let's not go lumping C and C++ together! C++ has quite a heavier runtime to manage stuff like exceptions and RTTI! (though, to be honest, I don't know what's a C++ program's runtime requirement if compiled with -fno-exceptions, -fno-rtti and the like)
    - stormbrew 12y ago
      Generally speaking the heavy part of both exceptions and rtti are in codegen (ie. the amount of code generated by the compiler), not in the 'runtime'. Exception jump tables and typeinfo objects are calculated as part of the compile and just referred to at run time. For example, this is the part of libsupc++ (effectively gnu's c++ "runtime") that deals with throwing: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/eh_throw.cc https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-...
leeber 12y ago
what the hell am I reading?
- killertypo 12y ago
  A painfully simple logger that makes use of Rust language features to ensure that it's allocated only when it is used, is RAII safe, and is mostly memory safe. A lot of boilerplate C or C++ code was eliminated, and while we never see the actual assembly, we're told that it would generate similar instruction sets to the C C++ implementations. So we should get pretty good performance out of it!?
  - comex 12y ago
    I mean, it'll produce similar assembly to C++ code that does the same, but grabbing a mutex for every log message is not going to give you amazing performance. That's okay in this example, because the log seems to be compiled out by default and only used for debugging Servo, but if you're gunning for performance I'd suggest using thread-local storage to store logs per thread without any atomics and aggregating on a timer.
    - killertypo 12y ago
      true and it does suffer from deadlocking (which the author states is a possibility, if one thread never releases the mutex)! Either way, it is a very lightweight implementation and Rust does shine here.
killertypo 12y ago
Much like Go! i'm not a big fan of languages whose includes are managed as such: [dependencies.lazy_static] git = "https://github.com/Kimundi/lazy-static.rs" Does Rust, like Go, have tools for freezing dependencies? So when the git project changes, you're not left wondering why a project has sudden bugs not seen before? I love the idea of how easy these can be included in a project, but I dislike leaning on a public repository that may change at a moments notice. For as much as I hate Maven for some reasons, I do appreciate the ecosystem and the ease at which I can...say, ask for a specific version of a specific artifact - ensuring my application will always build.
- ben0x539 12y ago
  Yeah: http://doc.crates.io/guide.html#cargo.toml-vs-cargo.lock http://doc.crates.io/guide.html#cargo.toml-vs-cargo.lock
- dbaupp 12y ago
  I'm not a Go expert at all, but I believe Cargo (the dependency management tool) far surpasses Go in this respect. One of the main design goals for Cargo is reproducable builds. E.g. the first time anything is build Cargo will create a Cargo.lock[0] file that fixes the dependency at the exact commit that the build used, so one can come back in a year and rerun to get the same result (assuming upstream hasn't edited their history). Upgrading/changing a dep then requires explicitly calling `cargo upgrade`. One can also manually specify versions and exact commits[1] in the Cargo.toml (the file written to specify those deps), e.g. [dependencies.lazy_static] git = "https://github.com/Kimundi/lazy-static.rs" version = "1.1" [0]: e.g. https://github.com/servo/servo/blob/master/Cargo.lock https://github.com/servo/servo/blob/master/Cargo.lock (machine generated/consumed) [1]: http://doc.crates.io/manifest.html#the-%5Bdependencies.*%5D-sections http://doc.crates.io/manifest.html#the-%5Bdependencies.*%5D-...
  - killertypo 12y ago
    Thanks! I would much rather prefer being forced to specify a version than not. Consider building with more than one developer in mind. Or a developer joins the team a year down the road. Why waste anyones time not taking a moment to say "no we need v.1.1". Good to see none the less! TIL.
kodablah 12y ago
I have a question about 1.0. I know you can define your modules' stability, but how much of the modules that will be shipped with 1.0 will have LTS? Specifically I am wondering if I follow http://doc.rust-lang.org/guide-plugin.html http://doc.rust-lang.org/guide-plugin.html AFTER 1.0 if I'll still have to keep up with point releases because I am using the internal AST.
- steveklabnik 12y ago
  Everything has stability markers. Currently, user defined macros and syntax extensions are not marked as stable. Syntax extensions will absolutely _not_ be stable at 1.0, macro stuff is a bit less clear, expect to hear about this soon. That post is about syntax extensions, so yes, you'll have to be using the nightly build if you want to keep using them. They'll be considered high priority to stabilize, but given that they rely on compiler internals... I actually argued against writing that guide because of this, but eventually said okay.
- TheHydroImpulse 12y ago
  Syntax extensions and the compiler internals are most likely not going to be stabilized for a while. Committing to a stable compiler core is a serious effort.
Jare 12y ago
> When we pass or return an Event by value, it's at worst a memcpy of a few dozen bytes. There's no implicit heap allocation, garbage collection, or anything like that. I'm confused by this (total Rust newbie): wouldn't pass by value imply creating a new copy of the String with its own heap-allocated buffer? What does "no implicit heap allocation" refer to?
- steveklabnik 12y ago
  http://en.wikipedia.org/wiki/Return_value_optimization http://en.wikipedia.org/wiki/Return_value_optimization TL;DR: Modern languages can tell when you're going to be returning a value, and just place the return in the right place, rather than making a copy that'd just get thrown away. I believe this is what they're referring to. It also might be talking about how just the tag gets copied, and not all the values. I think.
  - Jare 12y ago
    Yeah RVO is clear, I'm confused about the "pass by value" which I assume is as a parameter to a function, where a creating a copy is unavoidable in the general case.
    - steveklabnik 12y ago
      I pinged the author, and they said: > there is no implicit heap allocation, there is explicit heap allocation when you create the String, but not when you're just moving it around
- dbaupp 12y ago
  Ownership of the String is moved and the original variable cannot be used until it is reinitialised, it is not copied. Pass by value is literally always a shallow byte copy in Rust (not following pointers) and the Rust compiler must disallow further use of many variables to ensure safety.
  - Jare 12y ago
general_failure 12y ago
I have pretty much converted all my c++ code to rust. Hard to believe Rust is so approachable!
- mkesper 12y ago
  Do you have any examples you can publish?
Animats 12y ago
Rust is important, but that article isn't very good. Rust is at the level of C/C++, without an elaborate run-time system. It solves the three basic problems that cause most failures in C/C++ programs: "How big is it?", "Who deletes it", and "Who locks it". It does this without throwing a garbage collector at the problem, which means it can be used for operating systems and hard real time. The basic memory management mechanism is single-owner pointers, with language enforcement to make this work even as pointers are passed to functions. (Pointers passed to functions are "borrowed"; you can't keep a copy whose scope outlives the function return.) For more complex ownership, there are pointers with reference counts. For data shared across thread boundaries, there are atomic, locked pointers with reference counts. We need Rust. We're still seeing CERT advisories on buffer overflows in C/C++ programs, after almost four decades of C. The threats are getting worse, too; it's not script kiddies any more, it's governments. I just hope the Rust crowd doesn't screw up.
- lifthrasiir 12y ago
  You are correct and many Rust developers and contributors are aware of that point, but the OP wants to highlight the often neglected portion of Rust that may appeal to C/C++ users. Not every C/C++ user would move to Rust just for the safety (I did, but their mileages may vary). Some people look for the better abstraction, some look for the performance, and some others look for just fun. Rust is trying to appeal to many of them, not just the paranoid C/C++ developers; I think this article is very adequate for them.
  - Animats 12y ago
    not just the paranoid C/C++ developers You're not paranoid when they're out to get you. The most recent US-CERT advisory: Alert (TA14-300A) Phishing Campaign Linked with “Dyre” Banking Malware (Adobe Reader vulnerability) "...memory corruption vulnerabilities that could lead to code execution". This has been going on for over thirty years. It's time for the suffering to stop.
    - pjmlp 12y ago
      The sad part of this whole history is tha thirty years ago, if you didn't had access to an UNIX system, C didn't had any value. Those of us in other systems already had better alternatives, but then UNIX was pushed into the enterprise and succeeded at that, with the outcome of thirty years of buffer overflows.
annnnd 12y ago
How stable is Rust these days? I am watching it from a distance (I have no suitable project ATM) and I had the impression that the syntax went through some major changes not too long ago (a year?). Is this a thing of the past now?
- mkesper 12y ago
  http://blog.rust-lang.org/2014/09/15/Rust-1.0.html http://blog.rust-lang.org/2014/09/15/Rust-1.0.html
- guelo 12y ago
  Rust 1.0 is expected in the next few months.
kbart 12y ago
Is anyone using Rust for commercial products of embedded systems? It looks like a nice language (at least to try), but I don't find it in many open-source projects. Are there any reasons besides being new and not-so-popular for that? Is it compatible with C/C++ libraries (I mean in practice, not that they should work)?
- shadowmint 12y ago
  Its perfect for that use, but 1.0 is still months away. No one is using it yet...
  - steveklabnik 12y ago
    There are two big production deployments of Rust, and a number of smaller ones. The two are OpenDNS and Skylight.io. That said, yes, doing so before 1.0 takes a special kind of organization.
- steveklabnik 12y ago
  > Is it compatible with C/C++ libraries (I mean in practice, not that they should work)? Rust has zero-cost FFI into C, but cannot call into C++ (without it doing an extern "c" of its own) due to lack of a stable ABI.
- MetaCosm 12y ago
  > Are there any reasons besides being new and not-so-popular for that? It has a level of flux that is astonishing (even compared to other pre-1.0 languages)... now, it could be argued that this is how a pre-1.0 should be, but it makes it very hard to build any serious project around it (note: a few companies have).

155 points by wofo 12y ago

I recently started looking at Rust. I somehow had this idea in my head that it was a weird language, but up close, it is quite a friendly beast. Interesting, though.

stormbrew 12y ago
It has gotten a lot friendlier-looking in recent versions, thanks to the reduction in odd type-punctuation for lifetime description. It's more uniform now.
- cheez 12y ago
  Those attributes that look like comments have to go. Geez.
  - steveklabnik 12y ago
    It's likely that they will turn into @foo rather than #[foo]. The proposal is still being worked on.
    - Argorak 12y ago
      I don't understand the problem. Rust doesn't have # for comments, and I find `#[random]` easier to the eyes then `@random`. Or are we speaking about `@[random]`? Then again, I've never been one for micro-syntax-discussions.
      - steveklabnik 12y ago
        The motivation doesn't have to do with it looking like comments: https://github.com/rust-lang/rfcs/pull/386 https://github.com/rust-lang/rfcs/pull/386
        Argorak 12y ago
        Ah, okay, thanks!
    - cheez 12y ago
      Good enough for me.
  - pjmlp 12y ago
    Too much shell programming?
    - dbaupp 12y ago
      A lot of popular non-shell languages use #, e.g. Ruby, Python, PHP.
      - pjmlp 12y ago
        Scripting languages, usually coupled with shell programming.
        dbaupp 12y ago
        That's not really a sensible association. A lot of work is done with those languages where shells are either not used at all, or are just a development tool (e.g. could be replaced by editor features). It seems rather strange to try to forcibly connect Python/Ruby/... and sh, rather than just grouping as languages that happen to share the # for comments. (Maybe they adopted it from shells originally, but the languages definitely stand on their own now.)
        pjmlp 12y ago
        I never used them for anything else other than scripts on steroids, as I care for application performance. Well, PHP is forced upon me by my ISP and I never bothered to change.
kaoD 12y ago
It is indeed a weird language. I've been rusting heavily for about a week (doing Matasano crypto challenges) and I'm still puzzled at lifetime errors. Managing lifetimes is hard to reason about (though this is not a problem with Rust, but with lifetimes... Rust just makes it explicit.) As soon as you start using generics things can quickly get out of control. Here's one of my function signatures: pub fn xor_together<'a, 'b, 'r, A, B, R, T, U>(iter_a: T, iter_b: U) -> Map<'r, (&'a A, &'b B), R, Zip<T, U>> where A: BitXor<B, R>, T: Iterator<&'a A>, U: Iterator<&'b B> If you get those lifetimes wrong, the error propagates and you end up having lifetime errors farther in your call chain, which are quite hard to debug. I'm not even sure those lifetimes are 100% right. Some other weird things include closures. There are several types of closures, not interchangeable with each other (nor with fn) and honestly I don't understand them (and couldn't find docs to explain them). I hope this changes as Rust stabilizes. I'm loving it so far, but boy... how hard it is.
- kibwen 12y ago
  Closures are soooo messed up right now, because we're in the process of replacing them wholesale but the new system is only half-implemented. As a result you're forced to choose between using closures that work but suck (the old system) or closures that don't suck but don't work (the new system). So don't judge us on closures just yet. :)
  - MetaCosm 12y ago
    I hope that when Rust hits 1.0 -- they take backward compatibility exceptionally seriously. The pre-1.0 path has been exceptional wild ride, and it has made me a bit gun shy about the language as a whole. I am no stranger to pre-1.0 languages, I have worked with lots of them, but none have been as frustrating (or interesting) as Rust... the question as to will Rust grow into a production language or an academic toy still remains an open one in my book. Reserving judgement until 1.0 is out.
    - steveklabnik 12y ago
      > I hope that when Rust hits 1.0 -- they take backward compatibility exceptionally seriously. We do and we will. It's one of the reason there's such churn right now: we can't keep doing that post 1.0.

amelius 12y ago

The best test of a language is to see if you can write the compiler itself in the language (step 1) and also if you can write the runtime system in that language (step 2). IMHO, both are required for a language to be considered a good "systems language", and a worthy competitor of e.g. C++. I know that the Rust compiler is written in Rust (step 1), but I'm not sure about the runtime.

dbaupp 12y ago
Rust is yes to both, although 'the runtime' is disappearing, replaced by just using the system APIs directly (that is, Rust will have no runtime beyond what C/C++ has). The non-Rust code in the main distribution is: - LLVM for the complier - hoedown (markdown parser/renderer) for the documentation generator - miniz for compressing the metadata stored in each library - a few other tiny wrappers[1] for which I see no reason other than inertia/low-priority for translating into Rust (e.g. there would be no particular build-system benefit to Rustifying them because C/C++ compilers are needed for the other things anyway) [1]: https://github.com/rust-lang/rust/tree/master/src/rt https://github.com/rust-lang/rust/tree/master/src/rt (the 'rt' = runtime name is a holdover from when the runtime was not written in Rust)
- AceJohnny2 12y ago
  > beyond what C/C++ has Whoa now, let's not go lumping C and C++ together! C++ has quite a heavier runtime to manage stuff like exceptions and RTTI! (though, to be honest, I don't know what's a C++ program's runtime requirement if compiled with -fno-exceptions, -fno-rtti and the like)
  - stormbrew 12y ago
    Generally speaking the heavy part of both exceptions and rtti are in codegen (ie. the amount of code generated by the compiler), not in the 'runtime'. Exception jump tables and typeinfo objects are calculated as part of the compile and just referred to at run time. For example, this is the part of libsupc++ (effectively gnu's c++ "runtime") that deals with throwing: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/eh_throw.cc https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-...

leeber 12y ago

what the hell am I reading?

killertypo 12y ago
A painfully simple logger that makes use of Rust language features to ensure that it's allocated only when it is used, is RAII safe, and is mostly memory safe. A lot of boilerplate C or C++ code was eliminated, and while we never see the actual assembly, we're told that it would generate similar instruction sets to the C C++ implementations. So we should get pretty good performance out of it!?
- comex 12y ago
  I mean, it'll produce similar assembly to C++ code that does the same, but grabbing a mutex for every log message is not going to give you amazing performance. That's okay in this example, because the log seems to be compiled out by default and only used for debugging Servo, but if you're gunning for performance I'd suggest using thread-local storage to store logs per thread without any atomics and aggregating on a timer.
  - killertypo 12y ago
    true and it does suffer from deadlocking (which the author states is a possibility, if one thread never releases the mutex)! Either way, it is a very lightweight implementation and Rust does shine here.

killertypo 12y ago

Much like Go! i'm not a big fan of languages whose includes are managed as such: [dependencies.lazy_static] git = "https://github.com/Kimundi/lazy-static.rs" Does Rust, like Go, have tools for freezing dependencies? So when the git project changes, you're not left wondering why a project has sudden bugs not seen before? I love the idea of how easy these can be included in a project, but I dislike leaning on a public repository that may change at a moments notice. For as much as I hate Maven for some reasons, I do appreciate the ecosystem and the ease at which I can...say, ask for a specific version of a specific artifact - ensuring my application will always build.

ben0x539 12y ago
Yeah: http://doc.crates.io/guide.html#cargo.toml-vs-cargo.lock http://doc.crates.io/guide.html#cargo.toml-vs-cargo.lock
dbaupp 12y ago
I'm not a Go expert at all, but I believe Cargo (the dependency management tool) far surpasses Go in this respect. One of the main design goals for Cargo is reproducable builds. E.g. the first time anything is build Cargo will create a Cargo.lock[0] file that fixes the dependency at the exact commit that the build used, so one can come back in a year and rerun to get the same result (assuming upstream hasn't edited their history). Upgrading/changing a dep then requires explicitly calling `cargo upgrade`. One can also manually specify versions and exact commits[1] in the Cargo.toml (the file written to specify those deps), e.g. [dependencies.lazy_static] git = "https://github.com/Kimundi/lazy-static.rs" version = "1.1" [0]: e.g. https://github.com/servo/servo/blob/master/Cargo.lock https://github.com/servo/servo/blob/master/Cargo.lock (machine generated/consumed) [1]: http://doc.crates.io/manifest.html#the-%5Bdependencies.*%5D-sections http://doc.crates.io/manifest.html#the-%5Bdependencies.*%5D-...
- killertypo 12y ago
  Thanks! I would much rather prefer being forced to specify a version than not. Consider building with more than one developer in mind. Or a developer joins the team a year down the road. Why waste anyones time not taking a moment to say "no we need v.1.1". Good to see none the less! TIL.

kodablah 12y ago

I have a question about 1.0. I know you can define your modules' stability, but how much of the modules that will be shipped with 1.0 will have LTS? Specifically I am wondering if I follow http://doc.rust-lang.org/guide-plugin.html http://doc.rust-lang.org/guide-plugin.html AFTER 1.0 if I'll still have to keep up with point releases because I am using the internal AST.

steveklabnik 12y ago
Everything has stability markers. Currently, user defined macros and syntax extensions are not marked as stable. Syntax extensions will absolutely _not_ be stable at 1.0, macro stuff is a bit less clear, expect to hear about this soon. That post is about syntax extensions, so yes, you'll have to be using the nightly build if you want to keep using them. They'll be considered high priority to stabilize, but given that they rely on compiler internals... I actually argued against writing that guide because of this, but eventually said okay.
TheHydroImpulse 12y ago
Syntax extensions and the compiler internals are most likely not going to be stabilized for a while. Committing to a stable compiler core is a serious effort.

Jare 12y ago

> When we pass or return an Event by value, it's at worst a memcpy of a few dozen bytes. There's no implicit heap allocation, garbage collection, or anything like that. I'm confused by this (total Rust newbie): wouldn't pass by value imply creating a new copy of the String with its own heap-allocated buffer? What does "no implicit heap allocation" refer to?

steveklabnik 12y ago
http://en.wikipedia.org/wiki/Return_value_optimization http://en.wikipedia.org/wiki/Return_value_optimization TL;DR: Modern languages can tell when you're going to be returning a value, and just place the return in the right place, rather than making a copy that'd just get thrown away. I believe this is what they're referring to. It also might be talking about how just the tag gets copied, and not all the values. I think.
- Jare 12y ago
  Yeah RVO is clear, I'm confused about the "pass by value" which I assume is as a parameter to a function, where a creating a copy is unavoidable in the general case.
  - steveklabnik 12y ago
    I pinged the author, and they said: > there is no implicit heap allocation, there is explicit heap allocation when you create the String, but not when you're just moving it around
dbaupp 12y ago
Ownership of the String is moved and the original variable cannot be used until it is reinitialised, it is not copied. Pass by value is literally always a shallow byte copy in Rust (not following pointers) and the Rust compiler must disallow further use of many variables to ensure safety.
- Jare 12y ago

general_failure 12y ago

I have pretty much converted all my c++ code to rust. Hard to believe Rust is so approachable!

mkesper 12y ago
Do you have any examples you can publish?

Animats 12y ago

Rust is important, but that article isn't very good. Rust is at the level of C/C++, without an elaborate run-time system. It solves the three basic problems that cause most failures in C/C++ programs: "How big is it?", "Who deletes it", and "Who locks it". It does this without throwing a garbage collector at the problem, which means it can be used for operating systems and hard real time. The basic memory management mechanism is single-owner pointers, with language enforcement to make this work even as pointers are passed to functions. (Pointers passed to functions are "borrowed"; you can't keep a copy whose scope outlives the function return.) For more complex ownership, there are pointers with reference counts. For data shared across thread boundaries, there are atomic, locked pointers with reference counts. We need Rust. We're still seeing CERT advisories on buffer overflows in C/C++ programs, after almost four decades of C. The threats are getting worse, too; it's not script kiddies any more, it's governments. I just hope the Rust crowd doesn't screw up.

lifthrasiir 12y ago
You are correct and many Rust developers and contributors are aware of that point, but the OP wants to highlight the often neglected portion of Rust that may appeal to C/C++ users. Not every C/C++ user would move to Rust just for the safety (I did, but their mileages may vary). Some people look for the better abstraction, some look for the performance, and some others look for just fun. Rust is trying to appeal to many of them, not just the paranoid C/C++ developers; I think this article is very adequate for them.
- Animats 12y ago
  not just the paranoid C/C++ developers You're not paranoid when they're out to get you. The most recent US-CERT advisory: Alert (TA14-300A) Phishing Campaign Linked with “Dyre” Banking Malware (Adobe Reader vulnerability) "...memory corruption vulnerabilities that could lead to code execution". This has been going on for over thirty years. It's time for the suffering to stop.
  - pjmlp 12y ago
    The sad part of this whole history is tha thirty years ago, if you didn't had access to an UNIX system, C didn't had any value. Those of us in other systems already had better alternatives, but then UNIX was pushed into the enterprise and succeeded at that, with the outcome of thirty years of buffer overflows.

annnnd 12y ago

How stable is Rust these days? I am watching it from a distance (I have no suitable project ATM) and I had the impression that the syntax went through some major changes not too long ago (a year?). Is this a thing of the past now?

mkesper 12y ago
http://blog.rust-lang.org/2014/09/15/Rust-1.0.html http://blog.rust-lang.org/2014/09/15/Rust-1.0.html
guelo 12y ago
Rust 1.0 is expected in the next few months.

kbart 12y ago

Is anyone using Rust for commercial products of embedded systems? It looks like a nice language (at least to try), but I don't find it in many open-source projects. Are there any reasons besides being new and not-so-popular for that? Is it compatible with C/C++ libraries (I mean in practice, not that they should work)?

shadowmint 12y ago
Its perfect for that use, but 1.0 is still months away. No one is using it yet...
- steveklabnik 12y ago
  There are two big production deployments of Rust, and a number of smaller ones. The two are OpenDNS and Skylight.io. That said, yes, doing so before 1.0 takes a special kind of organization.
steveklabnik 12y ago
> Is it compatible with C/C++ libraries (I mean in practice, not that they should work)? Rust has zero-cost FFI into C, but cannot call into C++ (without it doing an extern "c" of its own) due to lack of a stable ABI.
MetaCosm 12y ago
> Are there any reasons besides being new and not-so-popular for that? It has a level of flux that is astonishing (even compared to other pre-1.0 languages)... now, it could be argued that this is how a pre-1.0 should be, but it makes it very hard to build any serious project around it (note: a few companies have).