Rust in 2016

http://blog.rust-lang.org/2015/08/14/Next-year.html

by aturon • 11 years ago

371 149 11 years ago

jhasse• 11 years ago

Sounds wonderful! I especially can't wait for incremental compilation. I can't understand how others do any work without it.

steveklabnik14• 11 years ago

Since crates are the compilation boundary, and you can make projects out of multiple crates, larger Rust projects tend to be split up, even internally.

Take Servo, for instance: https://github.com/servo/servo/tree/master/components or rustc itself: https://github.com/rust-lang/rust/tree/master/src

Each of these subdirectories (basically, a few aren't) is a crate, so you'll only be recompiling stuff in the subdirectory you're editing. Incremental compilation will still help with projects like this, of course.

saosebastiao4• 11 years ago

Is it possible for rust to optimize across crate boundaries?

krat0sprakhar• 11 years ago

And you can do so in contexts you might not have before, dropping down from languages like Ruby or Python, making your first foray into systems programming.

I guess I'm one of those programmers who is quite alienated from systems programming - probably due to my daily work in Python / JS. The Rust lang book is quite good (great job @steveklabnik et al) but from my past experience I've found it easier to stay committed to learning a new programming language when I have a project that I can work on.

Can someone suggest a few "getting started" but useful systems programming projects that I can use as a test bed for learning Rust?

MoOmer• 11 years ago

Try re-implementing some of the GNU Core Utils in Rust [0]

[0] http://www.gnu.org/software/coreutils/coreutils.html

steveklabnik14• 11 years ago

Or contribute to the project that's already doing so: https://github.com/uutils/coreutils/

(I myself wrote a little wc for fun a month ago, still missing some compatibility things https://github.com/steveklabnik/rwc/blob/master/src/main.rs )

grayrest• 11 years ago

Is there an RFC or thread covering the IDE integration plans?

aturon3• 11 years ago

Not yet, but Nick Cameron (@nrc) has been holding talks with many IDE makers and plans to launch a "Rust IDE initiative" very soon.

SneakerXZ2• 11 years ago

It would be nice to have something to Atom. Like http://nuclide.io/ with built-in building pipeline, syntax highlighting, smart code completion, and error checking and some basic support for refactoring.

I would prefer that over plugin to Eclipse or Intellij IDEA.

thescrewdriver• 11 years ago

It would be fantastic if Jetbrains was building an IDE for Rust somewhere in their basement. One can only hope...

superfunc• 11 years ago

They are currently tackling C++(Clion), which would lead me to believe it is within the realm of possibility if they were so inclined.

6d65• 11 years ago

Glad to see the language evolve.

It feels great, once one gets used with the borrow checker messages.

One thing that could make the language better(and was mentioned in the post) is faster compilation.

Having programmed in Go, this may be one of its best points, just have a watcher that recompiles the program on change(and maybe run the unittests). Though it can be argued that not all types of programs benefit from such workflow, it's still one of my favorite things.

pcwalton9• 11 years ago

Yes, compilation speed is one of the most important things for us. It's a lot harder for Rust than it is for Go, because Rust has a much more sophisticated suite of optimizations (necessary for Rust's goals) and zero-cost abstractions. You can do a lot better if you're willing to trade runtime performance for compilation speed, and we aren't. But I'm confident that we can get there with incremental compilation and more codegen/typechecking improvements.

CyberDildonics• 11 years ago

There are plenty of situations where trading compilation speed for performance is useful as a workflow tool. Not every build needs to be optimized to fullest extent possible, either by Rust or by llvm.

endgame• 11 years ago

How is nobody talking about push-button cross-compilation? It could be huge! The only language that I'm aware of that does it at all well is C and that's because the only build tool that does it at all well is automake. But even then the library situation is very hit-and-miss. If rust nails this it's going to be awesome.

chimeracoder• 11 years ago

push-button cross-compilation? It could be huge! The only language that I'm aware of that does it at all well is C

I'm not familiar with the term 'push-button', but Go also does cross-compilation very well.

(In fact, on Go, technically all compilations are cross-compilations; it just happens that the target platform and architecture may match the platform and architecture of the current machine.)

I'm not sure if that's still the case in 1.5 onwards, since I know they changed some stuff to make it even easier to target other platforms and architectures, but it was the case previously.

Manishearth3• 11 years ago

I'm pretty sure that the range of platforms for which Go does cross compilation "very well" is quite small. Go has a sizeable runtime, and you need to have a version of the runtime that works on each platform (for exotic platforms you would probably have to write some of the building blocks from scratch). This isn't push-button, this is just "the distribution supports many common platforms"

For example, it seems like compiling to MIPS is not push-button for Go. On the other hand, Rust supports all platforms that LLVM supports, though you need a version of the stdlib compiled for that platform (you don't have to write any code like in the Go case, you just have to compile the sources with the right invocation). For push-button compilation, we just need to distribute these binaries.

TheHydroImpulse• 11 years ago

It would absolutely be huge! Writing some ARM firmware in Rust wasn't as straightforward as it could be.

caukajun• 11 years ago

As someone looking to use Rust primarily on the Raspberry Pi and other embedded systems, this is a big deal.

pjmlp• 11 years ago

Maybe because many of us used cross compilers across multiple programming languages?

posborne• 11 years ago

This indeed would be very cool! Right now things work relatively well with the biggest pain being the acquisition of std for your target.

If std and core could be made into first-class crates, then you could get rid of the need to find a pre-built version of libstd for your target. It would just be built when needed by a project.

This is what we currently do in zinc for core via the hack here: https://github.com/hackndev/zinc/blob/master/Cargo.toml#L27. Zinc doesn't use std (for obvious reasons). Right now, targeting a raspberry pi is much harder than it should be as a result of having to having to find an appropriate cross-compiled std.

That is, I want the steps for cross-compilation to be:

1. Execute `cargo build --target=foo`.

2. There is no step 2.

khyryk• 11 years ago

Certainly looking forward to the borrow checker improvements as it's quite tedious to work around the match borrowing problem.

steveklabnik14• 11 years ago

What's interesting to me about SEME regions/non-lexical borrows is that it's a great example of a tradeoff:

Right now, the borrow checker's rules are very straightforward: references live for the entire lexical scope that they're alive. However, the downside of this is that sometimes you want the scope to end early, and so you have to code around it.

With non-lexical borrows, the rules get much more complex: borrows are determined by the control flow graph, not lexical scope. However, you no longer need to code around those edge cases.

So the question of which is better really comes down to a question: do programmers find reasoning about lexical scope or the CFG more intuitive? It would appear the latter is the case, which is kind of surprising for me, but maybe it shouldn't be.

markus2012• 11 years ago

Can't you think of it as still being scoped - just more fine grained? Pieces of structs can be borrow checked (what you are using) instead of the whole struct?

Manishearth3• 11 years ago

Remember that Rust CFGs are much simpler than C++ CFGs (no goto, for one), and in general CFG analysis is simpler due to ownership. It's easier to reason about Rust control flow than it is about C++.

mtanski• 11 years ago

Same here, the borrow checker in it's current incarnation left a sour taste in my mouth. What made it worse, the language market keeps plugging the borrow checker as this great fully baked feature. And (like you said) in real life it's fairly easy to run into cases where the borrow checker has false positive that are hard to work around.

I was disheartening to see what it was not a priority to tackle it. There's long standing bugs (2+ years) filed in github against it. And so far the answer has been it's hard to fix this, so we're not going to do it yet.

I'm really happy to this development. I hope this is sooner rather then later (have to wait to 2016)

jebblue• 11 years ago

There are 5 hits on dice.com for "rust".

steveklabnik14• 11 years ago

Yes, there are few dedicated Rust jobs yet. Most organizations that are using Rust in production are using programmers they've already hired rather than hiring new ones specifically for Rust.

It's a newly stable language, these things take time.

puredemo• 11 years ago

And only the first actually refers to the language.

darksaints2• 11 years ago

I would easily pay 3x the Xamarin price for a Xamarin-like platform for Rust. And I'm pretty sure I'm not alone.

It's the perfect language for a mobile platform, and I would love to use the zero-runtime-cost abstractions without resorting to the C++ hand-grenade roulette. The fact that it has an ML heritage, with all the goodies that entails (ADTs, pattern matching, type inference, etc), is even better.

vvanders3• 11 years ago

Yup, put me in that camp as well.

brson3• 11 years ago

It's going to happen, and it's going to be glorious!

moonchrome2• 11 years ago

I think people overestimate Rust as an application programming language.

It has some nice features but at the end of the day their focus is safety above all else - this actually creeps up all over the place - requiring you to be explicit, APIs requiring you to deal with every possible error type (even the ones you don't really want to deal with), etc. Error handling was still very messy last time I checked.

You know what makes you productive with high-level (often dynamically typed) languages ? Optimistic programming - you write some code and do the least amount of work to run it and see how far it gets you. Maybe a part of it fails under some condition, maybe some default assumption turns out to be wrong, etc. ... You can live with that because you got something working in fraction of the time it would require you to handle all the edge cases and type out all the bits and peaces up front. The sooner you get to run the sooner you get to iterate.

And that's ignoring the cost to iteration time because of compile time.

Rust has it's design goals - it's trade-offs are decent for the context they are made in - but it isn't my idea of high productivity application programming language.

saosebastiao4• 11 years ago

My very first use case for rust was to replace a ruby script that was running too slowly. The script did some free form text parsing and mathematical postprocessing, and then dumped out a huge load file for SQLite. It took me much longer to initially write than the ruby script...but after throwing in all the debugging and error handling after the fact with the ruby script, I spent about half as much time writing it in rust. And that was with 2 years experience with Ruby and zero experience with rust. There is a lot to be said about a language that is strict, strongly typed, and with an emphasis on safety. If I'm shipping a product with my brand name attached to it, I would so much rather catch easy bugs at compile time than run time.

joliv• 11 years ago

Aaron Turon and Niko Matsakis gave a talk on this for their Rust Camp keynote, you can see slides on it here if you prefer that format:

http://rustcamp.com/schedule.html

cpeterso• 11 years ago

How long does Crater take to compile all (2792!) crates in stock on crates.io? It ought to be embarrassingly parallelizable. Is there a dashboard page showing the Crater results for rust nightlies?

brson3• 11 years ago

At the moment we are using 60 r3.xlarge spot instances each running a single build at a time, and as of a few weeks ago it took maybe two hours. It hasn't been optimized.

There is no web dashboard yet (the website[1] - which runs Rust! - is quite minimal), but it's coming.

[1] https://crater.rust-lang.org/

LegNeato• 11 years ago

I wonder if you can use Buck with its distributed cache to make this go way faster?

PudgePacket2• 11 years ago

Where does the money come from to pay for these instances? Is it Mozilla?

fpgaminer3• 11 years ago

I had the opportunity to work with Rust >1.0 recently, implementing an image processing algorithm. Knowing that the compiler was looking out for me, a wingman of sorts, was quite the pleasant experience. When coding in C I have a very paranoid mentality, constantly questioning every line of code and its impact on program state/memory. It results in my C code being almost always free of memory related bugs, but the work is absolutely _exhausting_. Rust was great in this regard, dramatically reducing the amount of mental capacity expended while coding. Either the compiler would catch the bugs, or worst-case a run-time assert would catch it and point me directly to the problem.

The major criticism I came away with, due in part to the type of program I was coding, was for Rust's lack of implicit type casting (more specifically, widening). What I mean is, adding a u8 and a u16 is an error in Rust. Rust will refuse to implicitly cast the u8 to a u16. These situations came up very frequently while implementing my program because I had to do a lot of optimized, low-level math. The scattering of type casts throughout the program resulted in clutter without any obvious benefit.

When I looked into the problem, the arguments I saw against it were often explanations that Rust is meant to be explicit and non-magical. But Rust, for example, already has type inference which I classify as "magical". Implicit type widening is hardly magical. And I don't see how it would be confusing or result in bugs, as long as only safe widening is done implicitly.

I think those involved in the Rust project were just scared off from it because of C's bizarre implicit type casting rules which result in bugs for typical programmers. I can understand that, but it's not like it can't be done better in Rust. Besides, if Rust is meant to be a system programming language, won't math between differing types come up often? And wouldn't handling those cases gracefully be a boon to productiveness in Rust?

aturon3• 11 years ago

I definitely agree, this is a pain point in Rust today, and it's something the core team would like to address. You might glance at the thread here for some of the tradeoffs: https://internals.rust-lang.org/t/implicit-widening-polymorp...

If we can reach consensus on a design, such a feature can be easily implemented. I'd love to see an RFC on the topic (https://github.com/rust-lang/rfcs)!

kzrdude3• 11 years ago

How to address this problem?

    fn foo(x: u32) { }
    let x: u16;
    let y: u16;
    foo(x * y);

`x` and `y` would have to be multiplied before they are widened to `u32`. This creates an overflow bug that may only be visible in the released code (release mode has arithmetic overflow checking off by default).

jcranmer2• 11 years ago

A smart solution could be to have arithmetic operators automatically coerce the types to the type of their result, if the result type is already known.

saurik2• 11 years ago

That same bug exists even if the function takes a u16.

renox• 11 years ago

Very interesting remark. How about: Disallow what you wrote, but allow

  fn foo(x: u32) { }
  let x: u16;
  foo(x);

This way you get the 'best of both world'?

rthomas6• 11 years ago

As a hardware guy who has never touched rust, and I know nobody will agree with me: the solution is to not have type inference. You knew you wanted u16 or whatever to begin with. For low level programming I think explicitly defining type makes so much more sense.

tomp5• 11 years ago

I'm not sure that's the solution

  int8 x = 12;
  int8 y = 84;
  int16 z = x + y;       // ERROR: compiler is stupid

pcwalton9• 11 years ago

Not having type inference is a non-starter in Rust. Lifetimes would be totally impractical, and you couldn't use closures.

tomjakubowski• 11 years ago

As a hardware guy who has never touched rust, and I know nobody will agree with me: the solution is to not have type inference.

How is that a solution to OP's problem?

prewett• 11 years ago

Here's why you might not want to have type conversion. I ran into this today:

class String {

  int find(char needle, int startIdx);

};

I ended up calling:

   int idx = find(startIdx, ';');

C++ happily converted my char to an int, and my int to a char, no warning or anything. Surprisingly, the code appeared to work for months, and then when I upgrade Xcode to the beta, it started failing. Weird.

I end up casting stuff when I do math, anyway, because I can never remember when 'int op float' and 'float op int' results in an int or a float, and every time I don't it ends up as a truncated int when I wanted a float in [0, 1]. So, a little more painful to have to cast stuff around, but at least you find out quickly about my find() bug and you don't end up with something like

   if (secondsFromMidnightInFloat / 86400 > .5) {...}

always fails. I can't tell you how much time I've wasted tracking something like that down, despite my diligence in adding (float). That and that stupid "->" for pointers drive me nuts. Even more than header files.

kbenson3• 11 years ago

From the discussion linked[1] in another reply at your level, I believe the proposed automatic type conversions are only for when there's no data loss, and there needs to be explicit conversions whenever loss of information is possible. That is, it's implicit for i32 -> u32, or i32 -> i64, but not for something like i32 -> i8 (such as the int to char conversion you mentioned), which would need to be explicitly converted.

1: https://internals.rust-lang.org/t/implicit-widening-polymorp...

blub• 11 years ago

The first case will be detected by -Wconversion, however you have to enable it.

For the second case, correct me if I'm wrong, but I think both float / int and int / float have a float result. In fact, pretty much all operations involving an int and a float will have a float result.

SloopJon• 11 years ago

As a Rust newbie wrapping a C API, I ran into a baffling error for something like wstr.s[0 .. wstr.len], where the s field is an array, and the len field is a u16.

I like static typing with inference, but I'm still getting the hang of the Rust type system. In this case, a little leniency would have been nice.

coldcode• 11 years ago

It will be interesting to see Rust and Swift evolve as Swift moves to the server side (at least on Linux). Both are modern languages although each has its own target users.

digitalzombie• 11 years ago

They should put having technical books on Rust as a goal.

I learn via technical books btw.

Does anybody know if there's a rust book coming out?

I mean Julia is having a book from Manning and they're not even version 1.

burntsushi• 11 years ago

There is an official book: https://doc.rust-lang.org/stable/book/

aturon3• 11 years ago

There's an O'Reilly book in the works: http://www.amazon.com/Programming-Rust-Jim-Blandy/dp/1491927...

And The Rust Programming Language (https://doc.rust-lang.org/book) is on its way to paper publication.

The newly minted Rustonomicon (https://doc.rust-lang.org/nightly/nomicon/) that covers deeper aspects of Rust is hopefully destined for the same.

mrec• 11 years ago

It's probably a niche interest, but do you know if anyone's working on a Rust equivalent of Stroustrup's Design and Evolution of C++? I found that book a huge help in grokking the "why"s behind the language, and gaining some degree of mechanical sympathy with it.

I appreciate that the vast majority of Rust's D&E happened in the open, so most of it's probably still available, but it's been a long and twisty road since Graydon's initial public post and picking out a coherent narrative from umpteen separate slowly-linkrotting fora would be no small task.

DominikD4• 11 years ago

All of these are great (really, not being smug) but FWIW neither TRPL nor the Rustonomicon address my needs (Rust by example is probably the closest). It may be related to the weird set of skills and needs I have but hey, I'll post about my experience anyway in case someone shares my POV. ;)

My background includes OS development (Windows COM), driver development (C for kernel mode driver and C for HW firmware development), web development (C#/ASP.NET and JavaScript - both in browser and Node.js), and most recently HW simulation using C++/SystemC. Mixed bag, I know. What I want to use Rust for is desktop app development. I could go C, but that's a lot of manual labor. I could go C# but I don't like paying cost of the runtime on desktop. I could go C++ but I don't like getting my soul crushed. I tested viability of Node (and Python, actually) for desktop apps but it just didn't fit my needs.

So I want to love Rust. And I kinda do. Initially I didn't like certain things (bits of syntax mostly) but I've learned to love them. The problem is: none of the resources tell me interesting stuff all the way through the system. I feel like knowledge could be laid out with all the details from "this is syntax" to "this is what happens" to "this is what you can/cannot do" to "this is why this happens" to "this is what this means to the compiler" to "this is what happens under the hood/in asm".

I'd also[1] love to have something that roughly maps rust to C and gives me clear explanation of pros/cons of various approaches. It wasn't immediately obvious to me if I can have static methods. Of whether it's important to have self mutable (or not) as a method param. Or how to organize structures now that I have to keep mutability in mind. I know this comes with time but I'd love a kick of sorts. :) Best ideas tend to come from reading existing pieces of code but rarely knows if author is worth mimicking. :S

Either way - I'm invested and I like what I'm seeing. Great work guys!

[1] or these could become one thing, dunno

gbersac3• 11 years ago

I have been one of the backers of this kickstarter project for a rust book : Rust Programming Concepts

https://www.kickstarter.com/projects/1712125778/rust-program...

Animats• 11 years ago

If they add 'reuse' of old compilation intermediate results, the test for whether the source has changed should not be timestamp-based. That never works reliably, which is why "make clean; make" is so common. The source files must be compared by some cryptographic hash.

dbaupp7• 11 years ago

Content-sensitivity is actually required for this to be most useful with Rust. The file isn't a hard organisational boundary with Rust, incremental compilation would work either at the module level or the function level (i.e. the goal is to be incremental on the actual structures the compiler works with).

In any case, it has so many more benefits than just being actually-correct (as you say), e.g. one can edit comments/whitespace without forcing rebuilds.

gregwtmtno2• 11 years ago

Is that how they're doing it now? (I have experienced some trouble with cargo detecting changes to source files on my Mac, but I can't reproduce it reliably enough to file a bug.)

dbaupp7• 11 years ago

The compiler itself (rustc) does no form of incremental compilation: it just takes an input crate and compiles it entirely, unconditionally.

I believe cargo (which calls out to rustc) is using timestamps at the moment.

gbersac3• 11 years ago

When I read it, I think two things :

1- Great job. This is both innovative and powerfull. Like the idea to test nighties on every crate available on github. I am sure no other language does it.

2- So much feature may be a little disappointing. Take specialization. It may be interesting, but I don't even understand what it is. And I am not a beginner anymore ! Don't you fear that, by adding more and more feature, rust will become like the language it is aiming to replace (c++) : a huge mess of feature ?

That being said, I am definitely a rust enthusiast (I bought the book https://www.kickstarter.com/projects/1712125778/rust-program...). Carry on !

steveklabnik14• 11 years ago

  > Take specialization. It may be interesting, but I don't even
  > understand what it is.

That's fair, it's hard to put a full motivation in these kinds of posts. The RFC contains the full proposal, as well as a motivations section that hopefully makes it more clear: https://github.com/rust-lang/rfcs/pull/1210

TL;DR: specialization lets you also implement a more specific version of something that's generic. This lets you take advantage of this extra detail for various ends, like making a particular implementation more efficient than a general one could be.

kzrdude3• 11 years ago

It's a very detailed but also complicated proposal. It seems like it aims at some kind of inheritance as well? I would prefer it it were simpler.

BonsaiDen• 11 years ago

For anyone interested in the talks from the recent RustCamp, the videos are now available: http://confreaks.tv/events/rustcamp2015

PudgePacket2• 11 years ago

"We plan to extend the compiler to permit deeper integration with IDEs and other tools; the plan is to focus initially on two IDEs, and then grow from there."

Any ideas which IDEs will be chosen?

steveklabnik14• 11 years ago

Visual Studio and another yet-to-be-determined one.

nnethercote• 11 years ago

Rust’s greatest potential is to unlock a new generation of systems programmers. And that’s not just because of the language; it’s just as much because of a community culture that says “Don’t know the difference between the stack and the heap? Don’t worry, Rust is a great way to learn about it, and I’d love to show you how.”

Wonderful stuff.

drewm19802• 11 years ago

Are compiler features to support writing something like libeigen still on the roadmap? rust is IMHO a bit of a non-starter for many engineering fields until it has a really good story for array math.

steveklabnik14• 11 years ago

That's more of language typesystem features, and they still are, but we're focusing on work that will make said work easier in the future, rather than going straight to it.

drewm19802• 11 years ago

Ok, thanks!

Fede_V• 11 years ago

I am very excited to see the focus on tooling. Rust is a kick ass language, but imagine how awesome it would be to have an IDE to help you with lifetimes, inline documentation, etc...

C#'s best feature is its integration with visual studio. Rust would greatly benefit from something similar.

Rust in 2016

Related Stories