Announcing Rust 1.7

For those that don't follow Rust very closely, I sent in numerous (well, something like "30") fixes to various libraries after this landed, and the vast majority of them involved adding ": Sized" in the correct place. So while it was true that it was breaking, it was easy to update.

We take breaking changes ridiculously seriously, and soundness is basically the only case where they make sense to do.

To elaborate, we use a tool called Crater to estimate the potential impact of breaking changes. It attempts to compile all of the packages on crates.io with a new version of the compiler to determine any regressions, effectively using Rust's public package repository as an extended test suite.

Here's Crater's regression report for the linked soundness fix: https://gist.github.com/nikomatsakis/2f851e2accfa7ba2830d#ro... . It detected four root regressions, which means that there were four packages that were relying on unsound behavior. This isn't necessarily the full extent of the regressions, however, because if we ship a compiler that breaks those packages, then any other packages that have the formerly-unsound packages as dependencies will obviously also break.

Having a concrete list of regressions also allows us to go through the ecosystem and submit PRs ourselves to bring the affected packages back to building, which is usually quite easy. Crater is a really, really great tool.

Well, beta for the _next_ release is already branched; it would be the one after that, at the earliest.

Yes, absolutely, if you haven't seen the WebRender video already you need to watch it. I haven't been this excited about a new technology in a while.

Why not both? :) Dropbox has an enormous amount of infrastructure in Go, but some of their most performance-sensitive software is in Rust. There's no need to dedicate yourself to a monoculture.

In any case, let's not put too much stock on version numbers. :P

Why would you abandon Go for Rust without reason? Go does certain things better than Rust and vice versa.

Sorry, attempted snark at the version numbering. In all honestly, I think Rust looks quite interesting it's just that I want more experience in Go before I look at anything else.

Go Rust!

But if you go to Rust, your Go skills will start to rust. :)

Thanks. It's interesting to see how the generated code changes across rustc versions!

I believe this is being discussed here: https://github.com/rust-lang/rust/issues/29754

We have been working hard and investing a lot into tooling, it's just not done yet. https://www.rust-lang.org/ides.html is a rough outline of what's in the pipeline for IDEs specifically.

>tooling is more important than the language itself

What makes you say this? Many programmers don't use IDEs or anything.

We do invest a lot into tooling. There just hasn't been a huge amount of work put into IDE integration yet. There's lots of other types of tooling: Cargo, rustfmt, clippy, Racer, good error messages…

It took a long time for Java IDEs to not suck -- and complex GUI applications aren't exactly the open-source community's strong point.

The way forward on that front would require, IMO, some external actor to smell profit in a Rust IDE. That has been sloooowly becoming more likely as the stdlib inches toward stability.

As others have mentioned, we have lots of tooling that isn't specific to any IDE. For more information about IDE support in Rust, see this page: https://www.rust-lang.org/ides.html

TL;DR: There exist Rust plugins for Eclipse, IntelliJ, Visual Studio, Atom, Emacs, Sublime Text, Vim, and VS Code.

We're also working on ways to improve the compiler to better support the IDE use case: https://github.com/rust-lang/rfcs/pull/1317

> I wish Rust team invested more into tooling

Among similarly new language, I think the strength of the tooling is one of the notable positives of Rust.

> and maybe introduced officially supported IDE

While I get that some programmers prefer IDEs and that IDEs might actually be generally preferable for some Rust use cases, I think there is a lot more utility in the Rust team focusing on lower-level tooling (which IDE and enhanced-editor-plugin developers can leverage) rather than focusing on an officially supported IDE.

I'm not sure Javas is a bood benchmark to compare a young language against when it comes to IDE support...

That said, in my brief experience with rust I got the impression that their tooling is very high quality for something so new. Have you seen how pretty their compiler error messages are, for example?

Speaking from someone who uses Java everyday and has built a company that mainly uses Java I can tell you the Java tooling is fairly irritating (and I like Java).

Java doesn't have really good canonical tools that ship with the JDK nor is there a necessarily an industry preferred choice (Javadoc is probably the only exception). This of course includes more than just build tools. The fragmentation is huge.

For example Java doesn't have a defined format tool like gofmt or rustfmt nor does it have a preferred build/dep system like crate (there are several ... maven, gradle, ant). Even more annoying is that unlike code completion and refactoring tools (Rust racer) for Java are tightly coupled with the IDE and there are really only two choices: morbidly obese and broke: Eclipse or trust fund expensive but works: intellij.

With Racer you can use whatever editor or IDE you like. I wish I had something like that for Java.

> maybe introduced officially supported IDE

I would much rather they don't do that and instead offer tools that can answer IDE-like queries (e.g. "Who calls this function?", "Where is this identifier defined?", etc.) and let people integrate that into Emacs, Vim, Atom, and other editors and IDEs. This brings all the communities together and doesn't dictate one particular tool over all others.

This is true. I tried to do something with Piston, but I couldn't figure out what the type of anything should be, because I could inspect functions to see what their parameter and return types were. I could follow examples, but they tended to use inline functions, which don't need to specify types.

In Swift you can just Cmd+Click to do this (assuming SourceKit hasn't crashed) and it's very useful for that kind of exploration.

Someone asked a similar question on /r/rust the other day, here's what I had to say:

Rust is a programming language. It's a general programming language, so it's good for a large variety of things. Different people have different reasons for using Rust. There are three large constituencies, as I see them: systems programmers, functional programmers, and scripting language programmers.

Before I get into details: all generalizations are false ;)

Systems programmers come to Rust because it's able to do the lowest levels of software: operating systems, device drivers, stuff like that. Where it improves on existing systems languages is "safety." The Rust compiler does a lot of compile-time checking to make sure you don't do things wrong. Existing languages force you, as the programmer, to double check your work. We have the compiler double-check your work, and force you to get it right.

Functional programmers see all that static checking, and it feels like home. But a home where they have significant speed gained. Functional languages can be fast, but not always C level fast. Rust is. It's easier to get that level of performance out of Rust.

Scripting language programmers come to Rust for two reasons: the first of which is to write extensions to their language for speed. You can write a Ruby gem in Rust, rather than in C. This is useful because this low-level stuff is not their expertise, and so the extra checks are really nice. Related: we have a lot of the nice tooling that scripting language folks have come to expect from their language. No need to write makefiles, we have Cargo. The second is sort of related, but these checks also mean it's easier to learn low-level stuff, so if they want to expand their universe, Rust is a nice way to do so. We're seeing a lot of people for whom Rust is their first systems language.

I didn't know where to put this one, but Rust focuses on a concept called "zero-cost abstractions." This means that a lot of our features that feel very high level are extremely efficient. You don't write manual for loops, you se iterators. You don't deal with pointers directly, but with references. Structures like Box and Vec do memory management, but you don't need a garbage collector, and you don't need to manually manage it, but you also don't need to explicitly call free().

These are very broad strokes. Lots of other people have other reasons too. But that's some of them.

I started using it for distributable command line executables. It compiles everything into a single binary and is easy to deal with. The upcoming sentry command line executable uses it for instance: https://github.com/getsentry/sentry-cli

I've been slowly iterating toward building "safe" abstractions around the Erlang NIF interface in Rust, because a broken NIF can bring down the entire BEAM VM, and I very, very much want to have the kinds of compile-time safety checks that Rust provides me when writing NIF modules for Erlang software.

For me it's become, "Anywhere I would use or have to directly interface with C; evaluate using Rust instead."

I wrote a post recently that gives a summary of my experience with the language so far and attempts to answer why and when someone should use it: https://www.jimmycuadra.com/posts/the-highs-and-lows-of-rust...

I'd say Rust is a generically sensible language, in terms of the modern state of the art of language design (that is to say, it has a powerful but lightweight type system and is designed in ways that are amenable to writing correct programs) - this sounds like a low bar but is surprisingly rare (at least for a language that qualifies as at all mainstream). Distinctive things are that it compiles to native code and has manual but safe memory management (i.e. you have to tell it what the lifetimes of your values are, unlike a garbage-collected language, but you'll get compilation errors if you do it wrong, rather than silent memory leaks or crashes).

It's a reasonable first choice for when you absolutely need to avoid GC, or need code without a runtime (e.g. for embedding into another language). IMO a lot of people overestimate their performance requirements though (or assume that all GC languages must be as slow as Python/Ruby, or as slow to start as Java), and would be more productive overall writing in a language that doesn't require manual memory management and then spending a little time profiling. So for general-purpose programming where the target is native code I would recommend starting with OCaml or Haskell (if VM languages are suitable then also consider F# or Scala), and only falling back to Rust if you've spend a bit of time profiling and optimizing your app (or a representative benchmark/example) and find you really can't get the performance you absolutely need.

The current situation is "it works, but is not as easy as we'd like." We have plans underway to make it very trivial, but the needed infrastructure work isn't quite there yet.

A summary is "every Rust compiler is a cross-compiler, but you need a copy of the standard library for your target platform available." Getting said copy is what takes the work. In the future, we want it to be as easy as a call to the command-line, but for now, https://github.com/japaric/rust-cross is a good resource.

See also https://github.com/japaric/rust-everywhere , which is very interesting.

Not if there is bug in the soundness.

We already have a stable version. The only breaking changes we are seeing are soundness-related bugfixes, and crates stop compiling because they rely on buggy behaviour.

Looks like 15 hours ago.

By default Rust statically links the standard library into every program. For binaries it also statically links to jemalloc by default to use as the allocator. This is a large constant factory that makes trivial programs significantly larger than C, but like all constant factors it becomes insignificant when n is larger.

Binary size is not a major concern for most programs, even those written in a systems language. If it is a concern for your use case, you can use dynamic linking and the system allocator to get the size down to the same scale as C.

That 250K is additive, not multiplicative. Hello World, which might be 10K in C, will be 240K+10K=250K in Rust. A larger program that would be 2M in C would be 240K+2M in Rust; the significance of that 240K reduces when you write actual programs (instead of hello world).

The size is due to a statically linked stdlib (also jemalloc, which you can decide not to use) -- your C program is tiny because your system has a stdlib it can dynamically link to. Rust can do this too, it's just not the default since in most cases this additive extra binary size isn't a problem.

Being a systems language does mean we should forgo sensible defaults.

The great wit, Stan Kelly-Bootle, once observed (about Turbo C): "It generated a 40KB executable when I wrote my first 'Hello, World!' program. After that, I dared not say 'Goodbye.'"

    $ cat hello.rs
    fn main() { println!("Hello, world!") }
    $ rustc hello.rs -C prefer-dynamic
    $ ./hello
    Hello, world!
    $ ls -al hello
    -rwxrwxr-x 1 lifthrasiir 9064 Mar  4 14:24 hello*

See other comments for the explanation.

You can go under 1k if you don't use the standard library: https://github.com/retep998/hello-rs