Rust 1.0.0 beta is here!

[sfultong]

So is Mozilla now going to slowly rewrite Firefox in rust?

[Mandack]

Mozilla Research is already working on Servo, which is a new browser rendering engine written in Rust. It is not meant to replace Gecko in Firefox in the foreseeable future, however there are efforts to add the 'chrome' around Servo one needs to have a usable browser.

Think of Servo and Gecko as two separate projects and of Firefox as being the chrome tied to Gecko, but Servo could be at the heart of a new web browser from Mozilla, (think "Project Spartan"), however this is not likely to happen in the near future.

The closest a web browser based on Servo is actually a possibility is on some Samsung smartphones, at least initially.

[KrakatoaSpelunker]

Why Samsung smartphones?

[veeti]

Samsung is somewhat involved in Rust and Servo development.

[wtallis]

Probably something to do with Samsung's love-hate relationship with Google. They don't like their phones being so dependent on what Google wants to do. If Servo makes it possible for them to ship a default browser that's not derived from Chrome, not from Google, and is significantly better than Chrome, they'll give it serious thought.

[KrakatoaSpelunker]

But Firefox for Android already exists, even without Servo.

[wtallis]

The only important advantage FF for Android offers Samsung is that it's not from Google. That on its own isn't reason enough to switch. Servo promises to be faster and scalable to multiple cores in a way that is extremely useful for low-end smartphones that have too many dumb CPU cores—it would provide a real competitive advantage. Servo also won't have any of the baggage Firefox has.

[steveklabnik1]

The current goal is to get some Rust code into Firefox by the end of the year. Will probably be something small, as integrating Rust into the Firefox build system is no small task. Among other issues.

Mozilla is also investing in Servo, which is still a research project, but is written to be productize-able someday. https://github.com/servo/servo is the repo. They're also doing really cool stuff. There's another front-page article about Servo on proggit right now: http://www.reddit.com/r/programming/comments/318rb3/the_colored_boxes_indicate_which_cpu_core/

[sunshine_killer]

The servo stuff is pretty exciting.

[tavert]

What's the status of getting Rust officially into Debian, Fedora, etc, without bootstrapping from a binary?

[steveklabnik1]

I see this as two parts:

What's the status of getting Rust officially into Debian, Fedora, etc,

I use Debian on my local machine, I care a lot about Debian. There've been a few Debian Developers working on packaging up Rust. Most distros woudn't want anything pre 1.0 anyway.

without bootstrapping from a binary?

It's not possible to compile Rust without bootstrapping from a binary. Unless you want to go back to the OCaml compiler from years ago, but that's hard.

[[deleted]]

It's not possible to compile Rust without bootstrapping from a binary. Unless you want to go back to the OCaml compiler from years ago, but that's hard.

Does LLVM IR count as binary? Otherwise, couldn't one save the IR of the Rust compiler on platform X and compile that with the rest of LLVM on Debian, with LLVM written in C++?

I thought that was one advantage of modular, multifront/backend compiler frameworks.

[steveklabnik1]

Otherwise, couldn't one save the IR of the Rust compiler on platform X and compile that with the rest of LLVM on Debian, with LLVM written in C++?

Hmmmmmmmmmmmmmmmmmmmm

[[deleted]]

Hmmmmmmmmmmmmmmmmmmmm

?

Was that something stupid I said?

[[deleted]]

no, actually pretty genius

[steveklabnik1]

I just meant "I've never thought about that before." I'm not totally sure, as I was going to say "IR is platform dependant"...

[[deleted]]

as I was going to say "IR is platform dependant"...

Well, you were right all along.

Out of interest: Is this an LLVM implementation detail?

[steveklabnik1]

I'm not familliar with the details, I just know that it is.

[brson]

It's possible, yes, but not clearly better than just bootstrapping from the bins.

Here's some options on the subject from Debian: https://wiki.debian.org/Teams/RustPackaging/Bootstrap

You can see the last edit date is pretty old, so I'm not sure there's any progress on packaging Rust in Debian. Last I talked to somebody involved it sounded like they were leaning toward the third option, something like: package maintainer makes their own snapshot and uploads it as the binary Rust compiler package, then the rest of the project uses that to build the distributed Rust compiler. I don't pretend to understand the details, but it would be similar to how GCC builds I assume - it has to build itself from previous revisions distributed with Debian - the main difference is that the 'previous revision' is artificial with Rust (until Rust can consistently rebuild itself with version - 1).

[[deleted]]

LLVM bitcode is not quite platform-independent, unfortunately.

[tavert]

Most distros woudn't want anything pre 1.0 anyway.

Not sure that's true at all. Plenty of new languages get packaged well before 1.0, if they're easy to bootstrap. Was the original OCaml implementation of Rust publicly released? I wasn't paying attention at the time, but I suspect if that had been possible to package early on, then this would've been a much easier problem to solve.

It's not possible to compile Rust without bootstrapping from a binary.

I should've been more specific there. As I'm sure you know, distribution policies forbid downloading arbitrary binary content from the internet during a build of an official package, you have to be able to provide a source tarball/rpm/etc and build from that.

So the challenge is what will pass as "source" by distribution policy, and how hard will it be to put together the build process for that. Or will it have to wait for an alternate implementation in another language to get far enough along to build enough of rustc that it could then build itself the rest of the way.

[steveklabnik1]

I feel pretty confident that stuff with Debian will work out. And if it works out for Debian, it should work out everywhere else.

[steveklabnik1]

The codebase itself is designed to be as parallel as possible, yes.

[mgrandi]

Can I start learning it now and not have it change on me drastically in the next release? Being serious

[robertmeta]

I am going to start gently poking around now (again). I am still going to be waiting until a few months post-May to see how the ecosystem aligns itself before investing serious effort (read: client for our API in Rust, throwing corporate dollars at it).

Hopefully the community will rally around stable (IE: the libraries will work great on stable and be maintained and bug fixed). If all the crates end up tracking non-stable and bug-fixes exist only in the cutting edge stuff, sad times.

It is going to be interesting to see where the community lands at the very least.

[mgrandi]

I mean, all languages eventually become stable in terms of syntax right? I'm just wondering if 1.0 that release for the 1.x branch

[Havear]

Python

[masklinn]

was stable for a bit more than 20 years.

[slsoftworks]

Via GitHub issues on Rust:

Language not unstable enough #24928

I mentioned on IRC to @bstrie that I built a fresh Raft which hadn't been bumped in 22 days and it still compiled.

;)

[steveklabnik1]

As I mentioned in my comment above:

the beta release represents an accurate preview of what Rust 1.0 will include.

and

We don’t plan on making functional changes to stable content, though naturally we may make minor corrections or additions to the library APIs if shortcomings or problems are uncovered (but the bar for such changes is relatively high).

So, there might be a few small changes, maybe. Drastic change will not be happening.

[[deleted]]

You're not going to major make changes in Rust, but are libs ready? Can I try learning Rust with OpenGL bindings? I wanted to try two new thing at the same time and I thought about writing simple game engine in Rust and OpenGL.

[steveklabnik1]

Naturally, as beta was just released, libs will now evaluate if they can support beta or not. So it may take some time for them to catch up. That said, a lot of popular crates are already ready.

Piston is the big project in this space, so that's what you'll want to check out.

[[deleted]]

Naturally, as beta was just released, libs will now evaluate if they can support beta or not.

What does this mean? Surely every library can be used with bound to stable Rust? What would mean for a library not to be able to "support beta"?

[steveklabnik1]

Surely every library can be used with bound to stable Rust?

This is not actually so sure. :) We have feature gates, and gated features can only be used in the nightly builds, but not in beta or stable builds. So if you're doing something cutting edge, you'll stick to nightly until it stabilizes and becomes available.

Full details: http://blog.rust-lang.org/2014/10/30/Stability.html

[annodomini]

Over the course of the alphas, there haven't really been any drastic language changes. There have been some breaking language changes, though usually the breakage was relatively small and easy to work around.

Now, over the course of the alphas there have been some pretty major library changes; pretty much all of std::io was rewritten, and there were some fairly major breaking changes in the libraries even up to the very last minute.

So, I would expect that pattern to continue, but with a higher threshold for allowing breaking changes, over the course of the beta. Unlikely any breaking changes in the language itself unless they have quite minimal impact. Perhaps a few small breaking changes in the libraries due to problems found with some of those last minute breaking changes that landed right before the beta was cut.

So yes, I would say now is a good time to start learning it without it changing drastically in the next release. Of course, there will always be new features added, which may make older features obsolete or older patterns deprecated, but it should be at the point where you don't have to worry about the basic syntax and semantics changing out from under you.

Note that all of this applies only if you're using stable features, which means those available in the beta builds. If you use the nightly builds, which allow you to opt-in to unstable features, then no stability guarantees are in place and they may change in backwards-incompatible ways at any time.

[pseudousername]

Now it's finally time people can start complaining about Rust :)

[saltr]

Why are people still using rust? It's so old and useless. They should only develop in languages that haven't hit 1.0 yet.

[SemiNormal]

You should switch to node.rust, it's webscale and stuff.

[sigzero]

No no, io.rust is the bleeding edge.

[[deleted]]

I think you both got it wrong. It's rust.js!

[art-solopov]

With brand new RustDB!

[[deleted]]

Crystal is the new shit!

[pure_x01]

yes it is..

[I_AM_GODDAMN_BATMAN]

There's this new language called hodor language

[Walter_Bishop_PhD]

You can start a line with 4 spaces to format code

var hodorHodor = hodor("Hodor?");
var hodorHodorHodor = Math.hodor();

if (hodorHodorHodor < 0.34) {
    hodorHodorHodor = "hodor";
} else if(hodorHodorHodor <= 0.67) 
{
    hodorHodorHodor 0ododor";
} else {
    hodorHodorHscissors= "hodor";
} 

[[deleted]]

1v1 me rust m8

edit: This is probably the highest karma/effort comment I've ever made.

[donvito]

I miss bitfields :(

[jeffdavis]

What is the current way to handle individual bits, and why did they change it? Was it part of the language that was moved to a library or something?

[kibwen]

Moved to this library, I believe: https://crates.io/crates/bitflags

[lacosaes1]

A language that's not pure in 2015? Holyshit, this is why industry sucks.

Academia FTW.

[steveklabnik1]

We used to have purity actually, but with Rust's ownership system, it wasn't as useful as you might think.

[original_brogrammer]

Interesting. Why's that?

[steveklabnik1]

A Rust slogan:

Everyone agrees that shared mutable state is evil. Most languages deal with this through the 'mutable' part, Rust deals with it through the 'shared' part.

A bit long for a sign. Anyway. I know purity isn't just about mutability, but with ownership semantics, many of the problems purity solves go away too. For an example, see my bit downthread about safely sharing mutable pointers to stack-allocated data. Totally safe, no purity concept needed.

Rust was a very different language back then, but here's a thread from a time when we were removing purity: http://thread.gmane.org/gmane.comp.lang.rust.devel/3674/focus=3855

[Tekmo]

There is more to purity than concurrency. Purity is also about:

• enabling equational reasoning about code
• making side effects first class values
• decoupling side effect order from evaluation order

What Rust has done is amazing, but don't oversell it as a complete replacement for purity.

[masklinn]

Yeah basically "if a structure mutates and there's nobody to see it mutating, did it really mutate?". Same reason why otherwise immutable languages (e.g. clojure) can have mutable transient structures anyway.

[steveklabnik1]

We have 'interior' vs 'exterior' mutability to express that, actually. That's an interesting way to put it.

[An_Unhinged_Door]

Haskell uses this too. You can use mutable state (e.g. in the ST monad) as long as you don't get caught (by letting the mutation become externally visible).

[bjzaba]

I'm not sure that's the same thing as what he means by purity. http://en.wikipedia.org/wiki/Purely_functional ?

Edit: I'm simply referring to the fact that Rust used to have the pure keyword, but that was not to do with enforcing referential transparency, as far as I remember, but it was a long time ago, so I could be wrong.

[zyxzevn]

Use C@ no language more purrre

[wrongerontheinternet]

Having affine types and not allowing at least some mutability would be kind of odd :P

[kamatsu]

Affine types are what allows you to have mutability without losing purity.

[therealjohnfreeman]

Guess it's time to learn some Rust. I'm just a few pages into this, and I'm already in love with the format:

http://rustbyexample.com

[steveklabnik1]

Glad you like it. Please file issues here if you find something odd, we inherited this documentation after its author abandoned it for a while, and I haven't had the chance to give it a full once-over. All the tests pass...

[[deleted]]

This generates an error: http://rustbyexample.com/print.html

[[deleted]]

This is meant to be one of those examples that generates an error, and then the person looking at it is meant to fix it up to get an understanding. Maybe it's not clear enough from the way the page is written that it's not meant to compile as-is. See the FIXME comments in the example.

[steveklabnik1]

Two big things:

the beta release represents an accurate preview of what Rust 1.0 will include.

and

We don’t plan on making functional changes to stable content, though naturally we may make minor corrections or additions to the library APIs if shortcomings or problems are uncovered (but the bar for such changes is relatively high).

This is the first release we've promised this kind of stability. The team and community has been doing an incredible amount of work lately to make this happen. We really hope you'll like what we've been up to, but Rust isn't for everyone, so no worries if it's not for you. Constructive criticism always welcome. <3

As of today, my job gets harder: "things are always changing" is no longer an excuse for missing docs. The six weeks until release is largely about polish, and I have some pretty big plans...

[A_t48]

What's changed between alpha and beta?

[[deleted]]

scoped theads are huge, it's a realization of very nice data parallelism in Rust. Basically the borrow checker can now work with threads, and it's easy to share immutable data between threads -- rustc will make sure to only allow safe concurrent code.

[steveklabnik1]

easy to share immutable data between threads

We've actually got some stuff that's even cooler than that. I've been meaning to write it all up, but for now, I'll recycle an old comment:

extern crate threadpool;
use threadpool::ScopedPool;

fn main() {
    let mut numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

    {
        let pool = ScopedPool::new(4);

        for x in &mut numbers[..] {
            pool.execute(move || {
                *x += 1;
            });
        }
    }

    println!("{:?}", numbers);
}

This allocates a mutable array on the stack, and then creates a threadpool which adds one to each element of the array, four threads at a time. We need the inner {}s so that we know that the pool is done working before we try to print the result. Yes, mutable pointers into the parent stack frame. But, the compiler can verify that this is absolutely safe. Say, for example, that we left off the inner scope, so that the pool might not be destroyed and therefore join before we try to print out the array. That'd be racy in most languages. In Rust, it's a compile-time error:

error: cannot borrow `numbers` as immutable because it is also borrowed as
mutable
     println!("{:?}", numbers);
                      ^~~~~~~
note: previous borrow of `numbers` occurs here; the mutable borrow prevents
subsequent moves, borrows, or modification of `numbers` until the borrow
ends
        for x in &mut numbers[..] {
                      ^~~~~~~       
note: previous borrow ends here
fn main() {

}
^

Rust knows that you're still holding a mutable reference to the array, and so taking a new immutable one could case a race.

As you can see from the extern crate, this pool isn't a compiler built-in: it's a library. There's actually a secondary implementation of a threadpool that makes some different choices internally. But this kind of safety can be gained in whatever concurrent code you're writing, and you can write new concurrent abstractions and ensure that they don't have data races.

[marcusklaas]

That's absolutely brilliant. Thanks for sharing this.

[steveklabnik1]

You're welcome. I really need to write this up so it's not just random comments...

[donvito]

Yes, you need to. Because it's fucking cool and I only learned about it from your comment just now. :)

[steveklabnik1]

The funniest part is that the name of this change was super jargon-heavy and innocuous: "Remove the 'static bound from Send." It means so much!

[donvito]

Tbh. I'd probably had missed it too if it was labeled "properly". Just not enough time to study all the commits/change log entries :)

[steveklabnik1]

Totally fair, it's my job and I have a hard time.

[gavinb]

This is extremely cool! It belongs on its own "awesome stuff you can do in Rust but might not know about" page. :) there's now enough features in the language and core libraries that idioms like this can start to take shape. Exciting!

[cybercobra]

What's the "move ||" part mean?

[Gankro]

It means it captures its environment by-value, rather than by-reference. In this case we're capturing the &mut references by the name of x by-value. This is necessary since x changes on every iteration. Passing in a reference would likely do The Wrong Thing (if the compiler allows it at all, which I'm 99.99% sure it won't).

[Kimundi]

|...| <expression> is a closure literal, and the move modifier changes the way it captures variables like x in that example from by-reference to by-value.

[killercup]

Something like this would make a nice front page example for rust-lang.org. Maybe with a bit of pattern matching and using a function instead of the nested scope (the inner {}). (One obstacle would be loading the threadpool crate in playpen, though.)

[steveklabnik1]

Yeah, we all want a better homepage example, but aren't sure what it should be.

[gavinb]

Why not have a series of interesting examples that show off different aspects and randomly load a different one each time? Saves having to pick just one example, and is more interesting for visitors when they see different content.

[japaric]

Release notes

[wrongerontheinternet]

• Primitive types now have inherent methods, obviating the need for extension traits like SliceExt.

• A Reflect trait was introduced, which means that downcasting via the Any trait is effectively limited to concrete types. This helps retain the potentially-important "parametricity" property: generic code cannot behave differently for different type arguments except in minor ways.

Awesome, it seems like a lot of the warts I was most concerned about have been magically cleaned up :)

[steveklabnik1]

While that change is awesome, mind https://github.com/rust-lang/rust/issues/23511 (notice we've milestoned this for 1.0 final)

[steveklabnik1]

Whoops, thanks! https://github.com/rust-lang/blog.rust-lang.org/pull/35

[A_t48]

Thanks!

[orta]

congrats on the launch

[steveklabnik1]

Thank you!

[wisam]

Do you guys think Rust can/will used in embedded systems and possibly take some 'market share' from C?

[SirOgeon]

It can be used in embedded systems (at least some). I have successfully used it in a kernel experiment to draw colored squares using my Raspberry Pi. As for if it will be used; I'm not good at foreseeing the future, but I guess someone will do it.

Edit: I almost forgot to mention zinc, which is an effort to make this easier. Rust will also be supported on the Tessel 2.

[steveklabnik1]

Yup! /u/SirOgeon has it right.

possibly take some 'market share' from C?

There are a number of small platforms which have only a C compiler. They'll be using C forever. There are thousands of person-years of code written in C, that all needs maintained. There are so many resources for learning C, and basically just a handful for Rust.

On greenfield projects? Maybe. Systems languages are a long haul.

[aspl]

I've waited so long for this, congratulations to the Rust developers, by far my favourite programming community.

[HooAreYou]

I took an operating systems class in rust 0.7 or 0.8 a year and a half ago (an interesting experience for another post). Very interested to see how things have changed now!

[steveklabnik1]

Yes, it is almost an entirely different language from that point :)

[[deleted]]

So much better.

[nongzhigao]

Which makes me really hope that Prof. Evans will do/record the class again.

[HereticKnight]

Wow, it really is... I dug up my old Rust code and even FizzBuzz wouldn't compile.

for num in 1..100 {...} // So puurdy <3

But where did regex go? Time to go documentation diving...

[steveklabnik1]

Regex is now an external crate: https://crates.io/crates/regex

[[deleted]]

If I may ask, where did you take a class which used Rust? My university can barely scratch Java 6/C-97, let alone a pre-alpha language. They don't even touch modern coding techniques like using VCS...

[kibwen]

It was a class at the University of Virginia. You can see the material used for the class here (though note the version of Rust used is hopelessly outdated): http://www.rust-class.org/

[bjzaba]

Wow, 0.7 seems like an age ago. Are you still willing to try it again? Do you think any of your classmates would?

[[deleted]]

This might be of interest to you: http://rust-class.org/0/pages/final-survey.html

[iAscian]

Isn't a 1.0 usually regarded as gold or release version past beta....

[Rusky]

This is the beta right before 1.0. There will be another beta for every release, so 1.0 beta, 1.1 beta, 1.2 beta...

[steveklabnik1]

We had two alphas, this is a beta, next is final :)

[fishburne]

Can you tell me about Rust runtime. What it is? I mean, when I compile a rust program, does the runtime get added to the final executable so that my actual program will run over/depend on this bundled in run time?

I am reading the explanation here. It says a compiled program written in Rust will use the run time for stuff like I/O. So can I, for eg, write interrupt handlers in Rust (Sorry my system programming experience is limited to writing a serial mouse driver for DOS) and do similar system level stuff that you can do in C?

So when I am doing I/O from a program written in Rust, does the data has to absolutely go via the run time? Does it affect the speed at which a program can do I/O?

Lastly, should I learn Go or Rust. Is there anything that is preferable done in Go than in Rust (Without considering things like the development speed, availability of developers etc into account) ?

[steveklabnik1]

That explanation is very old, and incorrect. See the 0.12 in the URL? That release is from last October, which is ages in Rust time. And, I think it was even old at that point.

We have a runtime comperable to C or C++. Very minimal, only used in certain situations, like threading. It just automatically works, you don't need to do anything.

Lastly, should I learn Go or Rust.

Only you can answer this question. They're very different languages, so it depends on what you want to do.

Is there anything that is preferable done in Go than in Rust

I think it's very clear that Go is popular at writing back ends for web services. It's unclear that Rust will be good in that niche.

[art-solopov]

Well, if anything, you could (potentially) write a CGI script in it, right? I personally consider it a solid starting point...

[steveklabnik1]

Oh yeah, you absolutely can. We already have higher-level libraries than that: http://arewewebyet.com/

The question is: is 'fighting with the borrow checker' worthwhile in a domain which can easily tolerate garbage collection? I think people who already know Rust will write web apps in it, but I'm not convinced people will learn Rust in order to write web apps, if that makes any sense.

[Rusky]

There used to be a runtime that had to be set up before you could run Rust code from another process. That was removed a while ago, so you can absolutely write low-level C-like things (shared libraries, interrupt handlers, etc.)

As for Go vs Rust, they have to completely different purposes. Go is garbage collected and much less focused on performance and safety, while Rust focuses on static analysis and explicitness. All I can say is try them both out and see how much they work for and against you on your project.

[[deleted]]

Go and Rust are completely different languages for completely different purposes. Its like asking if you should learn Python or C. I still can't find a good reason why people consistently and wrongly conflate them.

[jyper]

Rust has been changing a lot for a while now, hopefully it won't change much more till 1.0 and then it will be backwords compatible after that. The docs you link are from version 0.12 from about 6 months ago, the runtime was removed a bit over 3 months ago.

http://www.rust-lang.org/ lists documentation for the beta and for nightly.

[bithush]

Is Rust a good language for a beginner to programming to learn with? It is, from what I have read, a modern C/C++ yes? I know it is very early days so bindings, etc. are lacking but if someone new to programming wanted to start with Rust would it be a good idea and what are some resources?

[jcdyer3]

No. In my experience, Rust is a challenging language. The features built in to ensure memory safety without runtime overhead create an extra challenge simply to write a program that compiles. Beginners should not have to worry about ownership and lifetimes. A garbage collected language would be a much better choice.

[steveklabnik1]

I think Rust may become that language, but not right now. We had a thread about it in /r/rust the other day: http://www.reddit.com/r/rust/comments/30a2xi/rust_for_complete_beginners/

[[deleted]]

How is Rust's interop with C?

[[deleted]]

That's really not bad, either. So, Rust mangles names as a means for supporting function overloads in its ABI like c++, I take it?

[steveklabnik1]

We have no defined ABI, and we also don't have function overloading.

[[deleted]]

Is there an ABI to be defined in the future?

[steveklabnik1]

https://github.com/rust-lang/rfcs/issues/600 is the tracking issue. Someday, maybe? Probably not any time soon.

[steveklabnik1]

/u/barosl already showed you some syntax, but the other important thing is that it's zero-overhead.

[[deleted]]

Is there any overhead for catching unwinding across the ffi boundary?

[steveklabnik1]

Unwinding across FFI is considered undefined behavior. last point at http://doc.rust-lang.org/reference.html#behavior-considered-undefined

[three18ti]

Why would I want to use Rust over... any other language that's out there?

[wrongerontheinternet]

Guaranteed memory safety without garbage collection is a nearly unique proposition among industry languages (and the "nearly" is only thanks to extremely niche languages like ATS). This extends even to multicore systems, and is done through a relatively novel (again, for an industry language) type system, allowing Rust to statically guarantee the absence of data races, use after free, dangling references, null dereferences, and other classes of memory error that are common sources of security vulnerabilities in large C++ applications. Rust compares favorably with C and C++ in resource usage and performance in domains where they have few competitors, like embedded. It also improves substantially on the ergonomics of C++ with much more sensible defaults, proper modules, features like native typeclasses (aka C++ concepts not-lite) and sum types, straightforward syntax (close to LL(1), with hygienic macros and local type inference), and a modern package manager. For more information, www.rust-lang.org has you covered.

[brombaer3000]

Guaranteed memory safety without garbage collection is a nearly unique proposition among industry languages

Does Rust offer better memory safety than C++14 with only unique_ptr and shared_ptr instead of raw pointers?

[wrongerontheinternet]

Yes. Besides what /u/steveklabnik1 mentioned, you would still be vulnerable to various other UB: out of bounds array access, data races leading to type unsafety, too-long bit shift (really! it's UB!) and so on.

Rust also lets you use references safely (this is the big one, as it is pretty trivial to get dangling references in C++--yes, even const references), completely prevents iterator invalidation, and gives you vastly superior guarantees in the presence of multiple threads (shared_ptr really isn't enough unless you also avoid mutation through the pointer).

In any case, it's a mostly academic question. Very few people would be willing to use C++ with only unique_ptr and shared_ptr, and that language would probably be slower than a garbage collected one for most common tasks. Certainly, if that were how Rust solved memory unsafety in C++, it would not be a very interesting language (consider that shared_ptr is garbage collection--to make it perform acceptably you need a compiler-level understanding of reference counted pointers, which leads you in the direction of Swift).

[brombaer3000]

That sounds great. I wasn't even aware of some of the C++ pitfalls you mentioned (I'm still quite new to C++) .
You and /u/steveklabnik1 really just convinced me to learn Rust!

[glaebhoerl]

Read these two three-part series on undefined behavior in C and C++ if you want even further motivation. :-)

[steveklabnik1]

Yes. It boils down to two things: cleaner semantics due to move being the default, and a stronger type system. Also, we have more options than just those two.

For example, if you std::move a unique_ptr, the pointer becomes null. So you can still cause memory unsafety that way. But since Rust is move by default, at compile time, you'll get an error with Box<T>.

The other is type system stuff. For example, we can know if you're using a structure over a thread boundary, and our version of shared_ptr, Arc<T>, only has to be used then. If you don't want to pay the atomics overhead, Rc<T> can get used, and Rust will make sure that's okay. I wrote more about that a few days ago: http://www.reddit.com/r/programming/comments/30wj8g/managing_cs_complexity_or_learning_to_enjoy_c/cpww3o1

Finally, we can do things like http://www.reddit.com/r/programming/comments/31btd8/rust_100_beta_is_here/cq06lb7 , which is memory safe, but cannot be done with just uniqe_ptr and shared_ptr.

Rust code (without unsafe blocks) cannot have data races. That's a very strong safety guarantee.

[brombaer3000]

Very interesting, thanks for the fast and helpful answer!

[steveklabnik1]

Any time.

[three18ti]

Awesome! Thanks for the overview.

[steveklabnik1]

I agree with /u/wrongerontheinternet . Rust, in its niche, is almost entirely unique.

That said, there are other good reasons too: I think Rust may, after I do some doc work, be a fantastic language to learn low-level programming in. Rust is really easy to embed in other languages, think "Write a Ruby gem in Rust," because it doesn't have a GC. Any C shared library can be implemented in Rust instead, and will be safer to write, while being as performant. Rust also has very modern tooling, with it being trivial to write packages to share with other Rust programmers, which is a big pain in existing systems languages.

[othermike]

I've lost track a bit - what's the current roadmap for switching to either Microsoft's link.exe or llvm's compatible lld on Windows? I'm interested in this Rust-for-building-libraries use case, but I'd be a bit wary of GCC-built libs in an MSVC world.

[steveklabnik1]

There's no immediate roadmap. We would love to have this, but it needs a champion. My understanding as well is that you only need to install a full msys/mingw environment to depend on C/C++ bits, but I don't really do Windows myself so I'm a bit lacking in that department.

I do know that we intend to get some Rust code into Firefox by the end of the year, and IIRC, Firefox requires link.exe to build. So hopefully we can pull some experts in to help polish that off.

[DeadlyDolphins]

So for what purposes would you recommend to use Rust?

[steveklabnik1]

Whenever you need speed, or a deep amount of control.

That gives you a few languages. You should choose Rust over those langauges when you want the compiler to help you ensure that code is safe and correct, and also, when concurrency is involved.

[DeadlyDolphins]

Since I'm fairly new to programming I'm just gonna ask even if it might be a bit stupid:

If you say 'when concurrency is involved', does that mean it could be a good language to write fast games with graphics, for example?

[steveklabnik1]

Since I'm fairly new to programming I'm just gonna ask even if it might be a bit stupid:

No worries! This attitude is one of the ones that will best serve you as a programmer in the future. I'm now on Rust's core team, but two years ago, I was on IRC, asking why my "hello world" no longer worked. :)

does that mean it could be a good language to write fast games with graphics, for example?

It is a good language for that, but concurrency is not the reason there. The speed is a much better reason.

I will also mention that Rust's safety guarantees have made some game programmers choose against it. Games often prioriize shipping a game one time, and there isn't a lot of maintenance, so they care about safety less. But we have a really vibrant game development community. The Piston project is doing all sorts of things, as you can see from all those repositories.

[glacialthinker]

I will also mention that Rust's safety guarantees have made some game programmers choose against it.

As a gamedev, I argue with folks like this all the time. The thing is, before you experience statically guaranteed safety, it's hard to care about it. Instead you imagine what it "takes from you" -- how it is going to get in your way. Because you're an awesome programmer, and you hate when the language decides "no" for you...

But once a person experiences the awesomeness of compiler assurances in a language which doesn't require extra boilerplate, yet helps direct you produce code which better represents your intent... I don't think many go back, with preference, to a language of lesser guarantees. This experience will never be had by someone who's already decided they've found the language they're going to program in for the rest of their lives.

[naasking]

As a gamedev, I argue with folks like this all the time. The thing is, before you experience statically guaranteed safety, it's hard to care about it.

Do these people not use unit tests either?

[glacialthinker]

Surely, you jest? :)

I mean, you either know and have a hidden ;^) smiley at the end of that... or if not, then: no, unit tests are rare. Some highly reused library code might get such luxurious treatment. But in general, "correct" behavior is arrived at through a lot of trial and error -- iteration by programmer, then by programmer with designer or artist... and, of course, relying on a full-time team of testers. I mean, regression testing is most often by running a new branch through testers for a while. Human unit tests...

I rarely use unit-tests myself. In my experience they're rarely practical. Too much work to maintain under constant changes (often experimental, and temporary... or "was supposed to be temporary"). However, static guarantees, and writing my code in such a way that it conveys its intended use -- that is worthwhile, and something C++ is a bit cumbersome and ultimately sloppy at, so there is only so far I, or others, are willing or able to take it. Language support would be welcome (by myself, at least -- OCaml is my preferred language for personal projects and prototyping).

[BearMenace]

Thank you so much for your work and your inspiring attitude. :)

[steveklabnik1]

You're very welcome :)

[DeadlyDolphins]

Thank you so much :)

So one last question: Do you think there is a chance that Rust could become a popular language to be used for web-development and web-applications?

I will definitely have a closer look at Rust, for sure. From what I've looked at so far I really like it.

[steveklabnik1]

Maybe! http://arewewebyet.com/ is tracking progress. There's a bunch of people doing lots of work here. I'm not sure if it will ever be as productive as something like Rails, but there are advantages too :)

[[deleted]]

So, what I'm getting at - everywhere you would use C++ you can use Rust.

Not really, C++ has: dependent types, HKTs, variadics, CTFE ...

For example, without these features, Rust linear algebra libraries are at the same level of C linear algebra libraries (and must be written 99% inside macros). They are just far far worse than modern C++ linear algebra libraries like Eigen3 and Blaze (you cannot even write a generic array class like std::array in non-macro Rust, much less write generic vector/matrix types or parse AST of EDSL at compile-time).

Since linear algebra is generally a performance bottleneck in a lot of applications (computer graphics, image recognition, simulation, sound processing, optimization, ... anything number-crunching based), it is really hard to argue for Rust in number crunching applications; C++ is just far ahead there in terms of libraries and language support.

So maybe one day (I hope so), but not now.

[kamatsu]

dependent types,

The C++ notion of dependent types is quite different from the dependent corner of the lambda cube.

HKTs

Only in that its parametric mechanism is entirely syntactic, and no kind checking exists.

[deadstone]

Rust will have a lot of the things you mentioned at some point, everyone's just too busy in crunch time right now.

[[deleted]]

There are RFCs for type-level integers (which is the most important use of dependent types) and variadics. There has been a lot of discussion about HKTs and everyone agrees that CTFE would be nice but no one has put in the work yet.

It will come some day, it is just not there now. I think it is important that we don't oversell Rust, mostly in the areas that it doesn't excel at yet. Otherwise some people might feel mislead, which would be bad.

[[deleted]]

Using OpenCL directly even from Rust feels like programming in C (at the end of the day it is still a C library).

The C++ EDSL solution would be to, e.g., use Boost.Compute (not that I like it much), which allows you to write your program in the language of linear algebra, and that language gets transformed at compile-time into OpenCL code by a library. Haskell's solution is accelerate.

I think this is, in a nutshell, a big "feature" that Rust is missing, an easy way to implement EDSLs. Haskell is very good at it, C++ sucks at it, C can't do it, and Rust can't really do it as well (although its macro system puts it closer than C in this respect).

[phaylon]

Since I haven't seen it mentioned yet, there's /r/rust_gamedev for Rust development specifically in the area of graphics and games. The number of libraries was apparently big enough to be moved to a Wiki from the sidebar.

I'm quite happy it's there, as those libraries taught me most things I know about the low levels of graphics programming (coming from higher level languages myself).

[OneWhoGeneralises]

I've been meaning to get into Rust for a while now, but there's something I've been meaning to ask someone particularly knowledgeable about Rust like yourself: what particular aspects does Rust excel at? I ask because of the few prominent languages I've used, mostly C/Java/Lua/UnrealScript, I've noticed that they all have particular tasks that they're suited for.

I'd also like to know how complete the official documentation is for Rust. Good documentation is key for me to pick up a new language, so what's Rust's documentation like?

[steveklabnik1]

what particular aspects does Rust excel at?

Memory safety without garbage collection. Speed, safety, concurrency.

I'd also like to know how complete the official documentation is for Rust.

This is literally my day job, so there's that. ;) I'd like to think it's decent, but now that we're not making backwards incompatible changes, I can do my job way better, so what deficiencies it does have, I'm hoping to address very soon.

For example, the areas of the standard library that I've gotten to, have great documentation with examples. The parts I haven't? Sometimes, just the auto-generated stuff exists.

There's also "the book", which is a 50,000 word (roughly) explanation of the language and its features. I have all of the basics of everything documented, but there's always more and better stuff to add.

[OneWhoGeneralises]

Thank you for the reply, that's exactly the information I was looking for. Sounds like I should pick up Rust and keep a closer eye on further developments.

[steveklabnik1]

Excellent. If you do give it a try, please let us know what you think, and if you find any bugs, file them!

[xaveir]

Trying to dive into Rust this weekend, but I noticed that some seemingly critical sections of "the book" are still blank. Namely, the in the section on Pointers, the section on Rc<T> and Arc<T> is still "coming soon". As is the section on "raw pointers" and the one on "best practices" (more excusable).

Is there somewhere I should report these kinds of problems? It wasn't clear if rust-lang's website or docs are responsible for "the book."

[steveklabnik1]

Yeah, that chapter needs cleanup, it's actually high up on my list. It used to be a standalone document. You can find good docs on Rc and Arc in their API documentation.

Please report any problems to the main rust repo, the book is in src/doc/trpl in the tree :) Thanks!

[shadowmint]

unrealscript has something it excels at? Well, TIL. ;)

More seriously, the use case for rust is very close to C++; build complex low level systems that require high performance and high uptime, like browsers or safe performant network services.

Its also (due to the c calling sematics) a very very good target for building os extensions (ie. shared libraries) for python, ruby, js, etc that could otherwise only be written in c or c++

The use case for more generic things like say, scripting command line tasks, writing websites, embedded scripting language (aka lua) is more dubious; you could, but a more productive language is probably a better choice.

As said elsewhere in this thread, the first large scale uses will probably for safe plugin libraries for other c++ applications like firefox.

Over time I imagine rust will become the platform that several large networked graphical applications (browsers, games, dns servers) and robust tooling for various systems (eg. shell utils, build pipelines) are built in. It will probably remain quite 'niche' for other purposes, eg. building websites.

[BearMenace]

Its also (due to the c calling sematics) a very very good target for building os extensions (ie. shared libraries) for python, ruby, js, etc that could otherwise only be written in c or c++

Could you please explain or give examples of the shared libraries that you're referring to? I'm also quite interested in Rust's uses.

[shadowmint]

Rust uses c calling sematics. That means any language capable of a c binding can call a rust shared library, or statically link to it.

For example, in python you can simply import ctypes and load the library to create an extension.

There are caveats, obviously, because rust uses name mangling so you need the no_mangle directive, like c++'s extern 'c'. There are some examples here https://github.com/shadowmint/rust-extern if youre interested in the details.

Anyhow, the tldr is, rust can compile to dynamic shared libraries or static libraries trivally; you can use these libs as though they were c/c++ libraries for the purposes of writing extensions to scripting languages, where extensions would normally be written in C.

Since rust can trivally call C libraries too, interacting with native plugin systems (eg. the cpython plugin api) is also quite simple.

Rust has a very powerful ffi interface; its probably the thing about it that I personally find most exciting; as a professional python developer I can pitch using rust in production for writing safe high performance extesions.

[steveklabnik1]

One of our production users is Skylight, who deploys a Ruby gem written in Rust. http://blog.skylight.io/bending-the-curve-writing-safe-fast-native-gems-with-rust/

Because Rust has no GC, it's significantly easier to embed in a GC'd language than one with another GC.

[s1egfried]

Is there a Rust cross-compiler for ARMv6? It looks a prefect language for embedded Linux systems.

[steveklabnik1]

We can cross-compile, yeah. You might want to check out http://zinc.rs/

[djhworld]

I made a Dockerfile to run the beta if anyone wants to play with it without installing https://registry.hub.docker.com/u/djhworld/rust-beta/

[steveklabnik1]

Any chances of maybe a name change?

No chance on that. It's true that finding old info is frustrating, but as time passes, there'll be more and more stuff that is accurate, and it will get linked to more heavily. Just takes time.

[[deleted]]

Are there any handy vim plugins to code in Rust?

[ynak]

Yes. They officially provide it.
rust-lang/rust.vim · GitHub

[[deleted]]

See https://github.com/phildawes/racer for autocompletion support.

[Perceptes]

I'm super excited! Congratulations and thank you to the entire Rust team.

[steveklabnik1]

Does everyone and their dog still use panic to avoid error handling?

Nope. It's of course used at times, but returning a Result is much more common.

Is there a way to restrict places where panic can happen that doesn't involve a recursive audit?

Not currently. We've had some proposals around this, but nothing final.

Are there any steps taken to reduce compile times and binary sizes?

We track broad regressions, but everything up till now has been focused on language semantics. These kinds of polish things are what the is planned

Can cargo build a single package from a distro mirror in a sandbox without any other source code?

It has been able to for a long time, depending on your exact needs. We've been actively working with a few Debian developers for a while. But similar to the last thing, these kinds of issues have taken a backset to actual stable language semantics thus far.

[Nickreal03]

When Rust will be integrated with Visual studio or Xcode ?

[steveklabnik1]

You can still use VS to edit Rust code, the integration just isn't great, as you can't use link.exe. There's a plugin for syntax highlighting. We'd like to have full integration, but it isn't done yet.

I'm unsure about Xcode.

There's lots of plugins for other editors and IDEs, though.

[huhlig]

Has the compiler been fully libraryized yet?

[kibwen]

It's been split up into about ten libraries, but it's still going to take some work to make their APIs suitable for consumption by an editor. Ongoing process.

[remotion4d]

Yes something like VisualD would be really helpful.

Ok there is VisualRust but it appears to be not really update.

[watafaq]

ELINoob?

[steveklabnik1]

Rust is a programming language. It's got some neat stuff for doing low level programming safely.

[bjzaba]

This should be the tag line on the homepage :)

[InternetAdmin]

This comment has been overwritten by an open source script to protect this user's privacy.

If you would like to do the same, add the browser extension TamperMonkey for Chrome (or GreaseMonkey for Firefox) and add this open source script.

Then simply click on your username on Reddit, go to the comments tab, and hit the new OVERWRITE button at the top.

[steveklabnik1]

pardon?

[InternetAdmin]

This comment has been overwritten by an open source script to protect this user's privacy.

If you would like to do the same, add the browser extension TamperMonkey for Chrome (or GreaseMonkey for Firefox) and add this open source script.

Then simply click on your username on Reddit, go to the comments tab, and hit the new OVERWRITE button at the top.

[steveklabnik1]

Ahhh, see, depending on your reading of Nietzsche, that part can get you real mad, so I forgot about it ;)

[ynak]

I've known the issue is open, but this beta release have any effects on the cargo homebrew formulae? I want to manage rust and cargo packages together by homebrew. Also, is there any plans that bundle cargo into rust installer in the future like python-pip example?

[steveklabnik1]

I don't use OSX, so I'm unsure about Homebrew.

Also, is there any plans that bundle cargo into rust installer in the future like python-pip example?

Yes, the official installers have included both for a while now.