12 ms·
Rust in 2016
- jhasse 11y agoSounds wonderful! I especially can't wait for incremental compilation. I can't understand how others do any work without it.
- steveklabnik 11y agoSince 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 https://github.com/servo/servo/tree/master/components or rustc itself: https://github.com/rust-lang/rust/tree/master/src 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.
- saosebastiao 11y agoIs it possible for rust to optimize across crate boundaries?
- vhbit 11y agoYep, it's possible to enable link time optimizations.
- steveklabnik 11y agoWith LTO, yes. I always forget if #[inline] does or not.
- phildawes 11y agoYes, #[inline] works across crates
- chrismorgan 11y ago#[inline] is all about cross-crate work; inside a crate, items not marked #[inline] may still be inlined by the optimiser, but it doesn’t do cross-crate inlining without #[inline] or LTO.
- dbaupp 11y agoNot all about. It gives an inline hint to LLVM, making it inlined more eagerly (even within a single crate) than the default.
- ben0x539 11y agoAre generics not inlined when appropriate even without #[inline] or LTO?
- kibwen 11y agoYou don't need the #[inline] attribute when generics are involved, because Rust already has to cross-crate-export function metadata when generics are involved because otherwise it would be impossible to monomorphize. At that point, LLVM will inline the monomorphized functions as it deems fit.
- krat0sprakhar 11y 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 11y agoTry re-implementing some of the GNU Core Utils in Rust [0] [0]: http://www.gnu.org/software/coreutils/coreutils.html http://www.gnu.org/software/coreutils/coreutils.html
- steveklabnik 11y agoOr contribute to the project that's already doing so: https://github.com/uutils/coreutils/ 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 https://github.com/steveklabnik/rwc/blob/master/src/main.rs )
- grayrest 11y agoIs there an RFC or thread covering the IDE integration plans?
- aturon 11y agoNot yet, but Nick Cameron (@nrc) has been holding talks with many IDE makers and plans to launch a "Rust IDE initiative" very soon.
- SneakerXZ 11y agoIt would be nice to have something to Atom. Like http://nuclide.io/ 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 11y agoIt would be fantastic if Jetbrains was building an IDE for Rust somewhere in their basement. One can only hope...
- superfunc 11y agoThey are currently tackling C++(Clion), which would lead me to believe it is within the realm of possibility if they were so inclined.
- vhbit 11y agoI doubt they'll be inclined in less than 2-3 years. Still, someone can create a plugin (afaik, there was one but abandoned)
- spdionis 11y agoExcept that Jetbrains probably makes most of its revenue from enterprise, and Rust has yet to see big enough adoption there (although there is some AFAIK). I'm not sure it's worth the investment yet. On the other hand this is a chicken and egg problem. A powerful IDE like the ones Jetbrains builds would increase Rust adoption a lot, and eventually Jetbrains would completely dominate that market.
- 6d65 11y agoGlad 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.
- pcwalton 11y agoYes, 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 11y agoThere 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.
- dbaupp 11y agoYeah, definitely. The compiler has a few features recognising this already, e.g. there's various levels of optimisation (0 through 3) and, more significantly, there's parallel codegen where the compiler will internally divide up a single crate into multiple compilation units and optimise/run code-generation on them in parallel (this reduces how much each compilation unit sees and so reduces optimisations like inlining etc.).
- whateveracct 11y agoWhile not every build needs to be optimized to the fullest extent possible, every build needs to be checked for correctness to the fullest extent possible. And since Rust does so much more than Go in terms of correctness, it's probably always going to be a no-contest between the two.
- endgame 11y agoHow 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 11y 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.
- Manishearth 11y agoI'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.
- dbaupp 11y agoI imagine the vast majority of cross-compiles for the core tasks that Go targets will be to x86 or ARM, which it does support well (from everything I've heard).
- khyryk 11y agoCertainly looking forward to the borrow checker improvements as it's quite tedious to work around the match borrowing problem.
- steveklabnik 11y agoWhat'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 11y agoCan'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?
- steveklabnik 11y agoYes, it's a scope, but not a lexical scope, hence the name :) I believe that 'borrowing part of a struct' is a different extension to the system, actually, though maybe they'll be put together. I haven't been involved in the pre-RFC myself.
- pcwalton 11y agoWe already do that. (See LoanPath in the compiler.) It's not a problem of reasoning about the structure of data--it's a problem of defining a notion of "overlapping control flow regions" that is simultaneously intuitive to the programmer, easy to compute, sound, and satisfies the ordering constraints we need (well-defined GLB, LUB, and partial order).
- jebblue 11y agoThere are 5 hits on dice.com for "rust".
- steveklabnik 11y agoYes, 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 11y agoAnd only the first actually refers to the language.
- saosebastiao 11y agoI 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.
- vvanders 11y agoYup, put me in that camp as well.
- brson 11y agoIt's going to happen, and it's going to be glorious!
- saosebastiao 11y agoPlease tell me more!
- brson 11y agoOK, imagine... You run a single command to instantiate a family of cross-platform Cargo projects, one your platform-agnostic backend, and one for each of your target platforms: Linux, Windows, Mac, Android, iOS, of course, but also the entire impending IoT down to the smallest real-time device. Your platform-specific projects come with safe Rust bindings to the system platform (ala Xamarin). Another single command builds and tests this from a single host system on an armada of virtual machines, emulators and cloud systems. Your tests run on a wide variety of standardized machine images, including those used for upstream Rust's own integration testing. Another single command packages this for various Linuxes and app stores, deploys to your devices and cloud services. Three commands, total world domination :)
- saosebastiao 11y ago
- joliv 11y agoAaron 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 http://rustcamp.com/schedule.html
- cpeterso 11y agoHow 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?
- brson 11y agoAt 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/ https://crater.rust-lang.org/
- LegNeato 11y agoI wonder if you can use Buck with its distributed cache to make this go way faster?
- PudgePacket 11y agoWhere does the money come from to pay for these instances? Is it Mozilla?
- kibwen 11y agoYes, Mozilla currently foots the bill for Rust's infrastructure. Currently there's no way to finance funding of Rust development directly, though we'd happily consider accepting donations of services from companies that provide these sort of things. :)
- fpgaminer 11y agoI 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?
- aturon 11y agoI 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-polymorphic-indexing-and-similar-ideas/1141 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 https://github.com/rust-lang/rfcs)!
- 11y ago
- coldcode 11y agoIt 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 11y agoThey 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 11y agoThere is an official book: https://doc.rust-lang.org/stable/book/ https://doc.rust-lang.org/stable/book/
- aturon 11y agoThere's an O'Reilly book in the works: http://www.amazon.com/Programming-Rust-Jim-Blandy/dp/1491927283 http://www.amazon.com/Programming-Rust-Jim-Blandy/dp/1491927... And The Rust Programming Language (https://doc.rust-lang.org/book https://doc.rust-lang.org/book) is on its way to paper publication. The newly minted Rustonomicon (https://doc.rust-lang.org/nightly/nomicon/ https://doc.rust-lang.org/nightly/nomicon/) that covers deeper aspects of Rust is hopefully destined for the same.
- mrec 11y agoIt'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.
- steveklabnik 11y agoI dream of doing such a thing someday. I'm not aware of anyone that's actively working on it. I did a talk at FOSDEM 2015 along these lines, which apparently got lost with a lot of them :/
- 11y ago
- Animats 11y agoIf 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.
- dbaupp 11y agoContent-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.
- gregwtmtno 11y agoIs 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.)
- dbaupp 11y agoThe 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.
- gregwtmtno 11y agoOh, interesting. That definitely sounds like the source of my problem. I'll have to look in to it. Thanks.
- gbersac 11y agoWhen 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-programming-concepts-book https://www.kickstarter.com/projects/1712125778/rust-program...). Carry on !
- steveklabnik 11y 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 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.
- kzrdude 11y agoIt'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.
- steveklabnik 11y agoIt's going to end up being a key part of the future inheritance proposal, but that's not a part of this RFC at all. > I would prefer if it were simpler. If you have thoughts about how to simplify it, please get involved in that thread! We don't actively try to introduce complexity, but sometimes, features are just inherently complex. There's also the case that sometimes features are easier to use than they are to define. I think this will be one of those kinds of features. At its core it just means that if you have a Vec<i32> and you also have impl<T> Foo for Vec<T> you'll be able to define an additional impl Foo for Vec<i32> and your Vec<i32> will use that one instead of the more general Vec<T> one.
- BonsaiDen 11y agoFor anyone interested in the talks from the recent RustCamp, the videos are now available: http://confreaks.tv/events/rustcamp2015 http://confreaks.tv/events/rustcamp2015
- PudgePacket 11y 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?
- steveklabnik 11y agoVisual Studio and another yet-to-be-determined one.
- nnethercote 11y 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.
- drewm1980 11y agoAre 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.
- steveklabnik 11y agoThat'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.
- drewm1980 11y agoOk, thanks!
- Fede_V 11y agoI 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.