back
93 comments
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.

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

I think thats a bit unfair on the article.

The memory management, and low level control make rust special. Thats what the author is talking about.

...why is an article that shows how to put rust into action bad?

Its a great practical article about dipping your toes into the water of using rust in my oppinion. /shrug

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.

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 (the 'rt' = runtime name is a holdover from when the runtime was not written in Rust)

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

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

If you disable rtti and exceptions, the only piece that needs runtime support is global constructors.

I've done it in the past with linker tricks to generate an ELF section with the list of ctor addresses. The asm that calls main (which if you're rolling your own runtime, you probably wrote as well) just calls them all right before it calls main().

C also has a runtime. It is called UNIX (POSIX).
You say that the runtime is disappearing. But, if LLVM is being used, then since it provides the JIT, I'd say it is a really big part of the runtime, actually.
The "VM" in LLVM is deceiving (and LLVM actually no longer stands for "low-level virtual machine"), its main use now is as an ahead-of-time optimiser/code-generator for the Clang C & C++ compiler. Rust uses it in this capacity too: optimised native code is emitted at compile time and no JITing is necessary.

Of course, LLVM can be used as a JIT (e.g. what Apple is doing with javascript), but Rust does not use or need it.

Wouldn't a better test be to see if you can implement something which the language is meant to be good at implementing? Even though a language might be a good fit for writing compilers (shown by being implemented "in itself"), that might not have anything to do with the domain it is meant for.

The "thing" that rust is meant to be a good fit for is implementing Servo.

In principle, sure, but in practice the main reason people seem excited about Rust isn't as the language in which Servo is implemented; it's as a C++ killer (note, for instance, this article). If it's going to fulfill that role, then being good at writing compilers/runtimes is absolutely essential.
Compilers/runtimes aren't what most C++ code does, surely?

EDIT: People are excited about it because of the promise of memory-safety (fewer crashes and security issues), as a primary driver. Servo is a proof that large-scale programs can be written in this way. They're not just excited about writing things in a new language for the hell of it.

How is C++ good for writing compilers?
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.
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.

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. :)
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.
Those attributes that look like comments have to go. Geez.
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.

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 (machine generated/consumed)

[1]: http://doc.crates.io/manifest.html#the-%5Bdependencies.*%5D-...

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.

> Does Rust, like Go, have tools for freezing dependencies?

What tools are you referring to Go here? There are a handful of extra-standard mechanisms you can use to make it somewhat better (through clever hacks on urls and such), but the expectation in go-land seems to be that 'freezing your dependencies' is 'vendor them wholesale into your git repo', which is not exactly robust. Go's story on "application will always build" is kind of notoriously bad.

I am referring to third party tools https://code.google.com/p/go-wiki/wiki/PackageManagementTool...

It would be nice to have it baked in, but thus is the life of bleeding edge development (of which I do not engage, in my safe Python Cocoon).

That is the current state of cargo, which is unfinished. There is currently work on a repository, much like rubygems/npm.

(git dependencies managed by the author always have the problem of the repos being renamed, vanishing, moved somewhere else)

I have pretty much converted all my c++ code to rust. Hard to believe Rust is so approachable!
Do you have any examples you can publish?
> 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?

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.
Right! Thank you!
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.

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.
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 AFTER 1.0 if I'll still have to keep up with point releases because I am using the internal AST.
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.

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

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

Its perfect for that use, but 1.0 is still months away. No one is using it yet...
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.

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?
Rust 1.0 is expected in the next few months.
what the hell am I reading?
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!?

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.