33 ms·

2017 Rust Roadmap

332 points by muizelaar 10y ago

cheepin 10y ago
I read through the Rust book, and the problem I was having with it and the other docs is that it was hard to map the Rust concepts with what actually runs when it is compiled. For a language that touts "uncompromising performance", it was difficult for me to find performance characteristics of the underlying abstractions and std library (for example, are algebraic data structures just tagged unions or does the compiler do more fancy things with them? What about iterators?). I'd really like to see a "Rust for C/C++ devs" guide that helps you figure out if you were using [some C++ feature] the way to get that behavior/performance with idiomatic Rust. Another thing that is still tricky for me is figuring out when I should use 'unsafe' blocks in my code. Is it to be avoided if at all possible, or should I go there any time the 'safe' part of the language is making it difficult to express what I want? The meme that Rust is C++ without SegFaults and or race conditions is a bit misleading since the actual guarantee is that you don't get SegFaults or Race conditions outside of Unsafe blocks, and any nontrivial project will make use of unsafe blocks.
- wyldfire 10y ago
  > any nontrivial project will make use of unsafe blocks. Sure! But that's okay. Just don't use 'quantity of unsafe blocks' as a metric of quality and you'll be all set. Think of it like so: don't use it until you have to and try not to have to. For me, that means consulting experts on IRC (etc), "How can I express this goal in idiomatic rust?" No different from learning C/C++ for the first time, IMO. And if no good way exists you may have to use unsafe blocks. Unsafe blocks aren't bad, just like #pragma-disable-this-warning and --static-checker-I-did-it-this-way-by-design aren't bad. They mean that you've thought critically about the pros and cons and you are going into this decision well aware of the risk. On the flip side they should be the first blocks to closely examine in the face of failures like segfaults/races/etc.
  - cmrx64 10y ago
    > > any nontrivial project will make use of unsafe blocks. I don't think that's actually true? Most projects make use of no unsafe outside of stdlib and a handful of crates.io crates.
    - vvanders 10y ago
      About the only time I end up using it is for ffi and uninitialized arrays on the stack.
    - mitchmindtree 10y ago
      This has been my experience also. I've written at least 40kloc of rust over the past couple years (including complex graphs with cycles, low-level DSP) and I could probably count the number of unsafe blocks I've needed on one hand. edit: This is not counting FFI though.
      - chrismorgan 10y ago
        Excluding FFI I might just be able to count the number on unsafe blocks I’ve needed on one hand. But honesty compels me to declare that for reasons of performance micro-optimisation, I’ve written a lot more.
      - DennisP 10y ago
        How do you handle cycles? I've seen discussions on places like /r/rust where people didn't seem to have any pleasant answers.
        mitchmindtree 10y ago
        I tend to use petgraph[1] when I need a graph-like data structure (the only time I've needed cycles). Super fast, distinguishes `Node`s from `Edge`s, lots of useful items for different kinds of traversal. [1]: https://github.com/bluss/petgraph https://github.com/bluss/petgraph
    - sidlls 10y ago
- anuragsoni 10y ago
  I am not sure if you have come across this "Rust tutorial for c/c++ programmers" https://github.com/nrc/r4cppp https://github.com/nrc/r4cppp but I found it to be nice when I was first exploring Rust (I had prior experience with C++). I haven't had to resort to "unsafe" blocks in the Rust I have written so far but "ffi" is one use case for unsafe blocks. Another resource that I have yet to read is "https://doc.rust-lang.org/nomicon/" https://doc.rust-lang.org/nomicon/" which seems to explain how to write unsafe Rust code.
- dikaiosune 10y ago
  Is there an equivalent guide to the compile-time representation of important constructs for those trying to learn C/C++? I haven't seen anything like that and it seems like most devs in that realm instead rely on experience and tribal knowledge (which is, AFAICT, how it often works in Rust-land right now). I agree it'd be great for Rust to have clearer official docs about some of these things, but it doesn't seem to me like this is readily available for most languages or runtimes. Re: unsafe, I think that's tough. My personal feeling is that many of Rust's selling points rely on minimizing the use of unsafe (i.e. limiting segfault-relevant portions of the code), and that there are frequently ways to make things work and also make them fast without using unsafe. What's an example where you found yourself thinking about using unsafe instead of a more complex safe construct? (Somewhat related to this, and especially for anyone reading who might try Rust, I cannot recommend getting on IRC strongly enough. The Rust IRC channels are by and large incredibly friendly and helpful, and for better or worse that's where a lot of the knowledge in the community is currently collected, not as much SO or blogs)
  - cheepin 10y ago
    > Is there an equivalent guide to the compile-time representation of important constructs for those trying to learn C/C++? Definitely. It was taught in school and there's pretty good guides for it online (maybe not caught up to c++11 and beyond, but the fundamentals are there). You're right that it is not readily available for most languages, but when you need to get serious about performance you either are going to have a guide or spend a lot of time looking at assembly/bytecode. To be fair, I'd probably still have to inspect generated code sometimes, but it's nice to have good instincts for how things run to guide your design/implementation so you can spend less time looking at assembly. http://www.agner.org/optimize/optimizing_cpp.pdf http://www.agner.org/optimize/optimizing_cpp.pdf
    - dikaiosune 10y ago
      I definitely haven't seen anything as comprehensive as the linked PDF for Rust (although that shouldn't be surprising given the extreme thoroughness of that guide and the age of C++). Probably a good project! When doing very performance sensitive things in Rust, I usually find myself asking questions a lot on IRC and looking at disassembly in perf. To answer some specific examples you cited above: I'm pretty sure that enums are (almost?) always equivalent to tagged unions. If you have an enum which doesn't contain any data, then I believe it's representation is just the tag. Iterators are just structs with methods, the various generic functions they implement are monomorphized and then optimized by LLVM.
- leshow 10y ago
  Most crates don't make use of unsafe, the stuff that I see that does use unsafe is mostly either embedded applications or stuff like the std lib. And even if you do use unsafe, you can still use it to build 'safe' abstractions on top of. the idea is that your unsafe code is quarantined and abstracted, and you build on top of it. std::collections is a great example of this.
- pcwalton 10y ago
  > for example, are algebraic data structures just tagged unions They're tagged unions with no implicit heap allocations. I guess we should at least document that in the reference (though we don't want to overspecify, because we do some tricks in the compiler to try to avoid leaving space for the tag if we can). But I don't think it'd be a good idea to document this straight away in the book: the goal is to make Rust easy to pick up, and adding more information than necessary when introducing enums (which a lot of folks will only see for the first time in Rust) isn't going to do people any favors. > What about iterators? The documentation for Iter explains this pretty well, I think: https://doc.rust-lang.org/stable/std/iter/ https://doc.rust-lang.org/stable/std/iter/ It even shows the exact implementation of (basically) Range, to give you an idea. That said, it would probably be worth calling out that most iterators are guaranteed not to allocate. Note, though, that that isn't a hard-and-fast constraint that implementors of the trait have to abide by—you can make your own iterators and implement them however efficiently or inefficiently you like. > The meme that Rust is C++ without SegFaults and or race conditions is a bit misleading since the actual guarantee is that you don't get SegFaults or Race conditions outside of Unsafe blocks, and any nontrivial project will make use of unsafe blocks. They'll make use of unsafe blocks transitively, by using unsafe code in the standard library or well-tested crates. Think of these unsafe blocks as part of the compiler: you trust the compiler to generate correct machine code when you type "a + b", so likewise you trust the standard library to do the right thing when you say "HashMap::new()". It is not the case that most projects should use unsafe themselves everywhere: that usually just makes life harder. The primary exception is if you're binding to C code, in which unsafe is unavoidable.
  - kalkin 10y ago
    Speaking of "guaranteed not to allocate", is there a way that you could express that in a type? Seems like that might be nice to have.
    - tatterdemalion 10y ago
      Not in Rust's type system. In a pure language, you could have some sort of "Heap" monad similar to the "IO" type in Haskell.
- Manishearth 10y ago
  > . Is it to be avoided if at all possible, or should I go there any time the 'safe' part of the language is making it difficult to express what I want? The main reasons to use unsafe code are when you're doing FFI and have to regrettably talk to C/++ libraries, or when designing new abstractions with a safe API boundary. It's tricky to ensure that the former is safe since you eventually have to trust C++ (but then, that's not Rust's fault). It's not hard to ensure that the latter is safe. Looking at a page of code and ensuring that it can't cause segfaults is a much easier task than doing it for the entire codebase. This is almost all the unsafe code out there. There's a bit of it used for doing manual optimizations. When Rust doesn't let you do what you want, often there are abstractions like RefCell that have a small cost that you can use (and they contribute to the overall safety). In case this happens in performance critical code, you can use unsafe again, but this is very rare. In Servo, for example, almost all of the unsafe code is of the first two kinds. I've been hacking on Servo for years and didn't write much unsafe code at all -- when I did, it had to do with talking to Spidermonkey, and even that was pretty rare. More recently I'm working on integrating Servo's style system into Firefox (which is C++), and only now have I been regularly writing unsafe code. Even for this project the unsafe code I'm writing abstracts away the inherent unsafety of Firefox's C++ so that others can talk to Firefox with safe Rust code. But many projects have no unsafe code at all. It's not that common to have unsafe code. > it was difficult for me to find performance characteristics of the underlying abstractions and std library (for example, are algebraic data structures just tagged unions or does the compiler do more fancy things with them? What about iterators?). Note that a C++ book won't help here for C++ too. What is a switch compiled down to? Does it use a jump table? :) But yeah, it would be nice to have a thing for this. I don't think it belongs in the official book, but it should exist :) ADTs are tagged unions. When non-nullable pointers are involved sometimes the tag is stored as a null pointer (e.g. `Option<Box<Foo>>` is a single pointer, and is None when null. Aside from that, nothing fancy. Iterators compile down to the equivalent for loops. I can't think of any stdlib iterator which implicitly allocates; they all operate on the stack. In general these are just zero-cost abstractions, they will compile down the the code you would have written with manual loops. This is a recurring theme with the stdlib and even crates from the ecosystem. "extra" costs for abstractions are eschewed in Rust and will often be documented when they exist. So as a rule of thumb assuming that a random abstraction doesn't have an overhead unless explicitly mentioned is good.
- steveklabnik 10y ago
  This is an area in which I haven't quite figured out how to communicate properly; I feel like I have a good understanding of how Rust maps to asm, but I don't know how to transfer that understanding to other people. I'll certainly be reading your link below, thanks for that!
  - tmzt 10y ago
    Would an updated and expanded Rust for C++ Programmers make sense as a companion to the book with references to concepts in the book along with low-level details on data structures or implementation? It would nice to see that and Nomicon more closely related and fully up-to-date. It soulds like an informal "specification" of #[repr(c)] or #[repr(packed)] for common platforms would also be useful for FFI.
    - steveklabnik 10y ago
      Yeah it'd be great to have.
- ezy 10y ago
  > it was hard to map the Rust concepts with what actually runs when it is compiled. This. The primary reason to choose rust is performance -- that is, you want more advanced abstraction/safety capabilities than C++, and you want that with the same or better performance. And performance implies CPU cost and memory usage/layout control. There really isn't any point otherwise. Therefore, going into at least a little bit of detail on the idioms and performance impact of those idioms is important. Rust is a supposed to be a systems programming language to replace C, do not pretend it's as abstract as ML in the documentation. What throws me for a loop when learning Rust isn't high level details like the borrow checker or sum types, it's what is happening with cpu & memory[1]. When things are copied, when they aren't, how much do the std derives cost, matching cost, sum type storage cost, etc. Because while the semantics are similar to C++, they are not the same. And you don't have to go nuts specifying it (compilers will differ), but at least give a general understanding/hint of what to do and what to avoid. To be fair, the doc does have this scattered about, but it doesn't feel a priority (There are many things I've had to search the web for or ask on #rust, or just look at disassembly for). [1] To take an extremely simple example, RVA is something Rust supposedly does much more consistently than C++, thus returning a new struct by value to be placed wherever is idiomatic. However this isn't called out very clearly (the last time I checked) in the doc, and to a C programmer, it feels very wrong. Stuff like this is extremely important, otherwise we'd just ignore performance and use a JVM based language with the same (or better) abstraction features and a faster compiler. :-)
dikaiosune 10y ago
It's important to note that this is an RFC which has been proposed, and there's likely to be a good deal of discussion and revision before it's merged/adopted as the official 2017 roadmap. The conversation can be followed/joined/whatever here: https://github.com/rust-lang/rfcs/pull/1774 https://github.com/rust-lang/rfcs/pull/1774
- collinmanderson 10y ago
  "accordance with RFC 1728" - could they have chosen a naming scheme so their documents are not confused with the _real_ RFC's? Even RRFC 1728 would helpful. Or maybe just #1728?
  - tatterdemalion 10y ago
    Lexical scope. You should assume an RFC cited in a Rust RFC is a Rust RFC, you're in the Rust RFC scope. If an IETF RFC is cited in a Rust RFC, it won't be ambiguous.
  - Can_Not 10y ago
    Why do "the _real_ RFC's" have exclusive rights to that term?
kalmar 10y ago
This is a better link, as it will include the discussion: https://github.com/rust-lang/rfcs/pull/1774 https://github.com/rust-lang/rfcs/pull/1774
gravypod 10y ago
> 1 in 19: lack of IDEs (1 in 4 non-users) I expected that to be higher actually, but that's still the only reason I don't use the language. I've come to rely heavily on IDEs. Whether right or not it's a huge factor in my decision to wait for the language.
- vvanders 10y ago
  If that's the case I highly recommend giving VSCode a spin. With racer I've got solid code complete, goto def and docs. They've also been making leaps and bounds in terms of features so I can only imagine it improving even more.
- raindev 10y ago
  I've been writing Java in Vim from time to time for 3 years. Rust is much more pleasant to deal with in a plain text editor. I encourage you to give it a try.
- unfamiliar 10y ago
  What kind of IDE support do you typically use that isn't handled by a modern text editor (such as go to definition, variable renaming, find and replace, etc)? I'm starting to use CLion for my C++ work now, because "go to definition" is much more reliable than most editors can manage with C++ code, but I find that most of the fancy refactoring features like extracting functions or subclasses are not used often enough to be really useful.
  - gravypod 10y ago
    The features I need are: - Refactoring Support (rename variable, class, function) - Code Folding - Automatic type checking - Automatic error detection (tells me when syntactical or other errors are made) - Built-in documentation loading/display on hover of cursor. - Same thing as above except with any documentation I add myself on a function. - Debugger with comment overlay of values (like PyCharm) - Dependency management/Building/Deploying all a *button* (not 10 commands) away - VCS integration - Automatic code formatting - Automatic code "cleaner" (change for (int i = 0; i < arr.length; i++) to an expanded loop for example) - Automatic import cleaning - Automatic project creation for basic use cases (console, GUI, maybe a web framework) - Change CWD/environment variable for running the program - GOTO definition - A Graphical User Interface (Graphical being the biggest requirement) Outside of all of those, there is a much much much more important feature: Auto Complete. A smart auto complete. An autocomplete that understands the type system and the function's return types. For instance if I am typing: String sub = someString. It shouldn't recommend "length()" as well as in the case of: String lengthStr = Integer.toString(someString. It should recommend things that return an integer. This needs to be fast and needs to be non-case-sensitive. Also, if I am typing Lis It should recommend List, ArrayList, etc in that order with the closest thing up front. It should also in the recommendation screen show documentation, a link to official documentation, and possibly an example of how to initialize/use the code. If something isn't imported and so it's not currently usable, if the user clicks enter or whatever on the auto-complete screen you should import it. If it has that, and has that working quickly, and has that working completely it's a "real" IDE in my book. That list is just "wants", this one thing is a "need" If I had that for rust, I'd switch over to rust as my main language. Anything that doesn't have something like that will never compete with Eclipse in ease-of-adoption in my book.
adamnemecek 10y ago
I would also suggest taking a page out of Apple's playbook and providing some official sample apps like https://developer.apple.com/library/content/navigation/#section=Resource%20Types&topic=Sample%20Code https://developer.apple.com/library/content/navigation/#sect.... Reading the books is one thing, but seeing the patterns actually used is another. You don't need as many as Apple, only a couple really, but make sure they are well written and straddle a couple of use cases. And like go crazy with the idioms, I want to see the most idiomatic Rust code. When learning a new platform, it's always frustrating having to hunt for good code. I actually find these similarly important as docs (maybe even more because I tend to reference good open source for much longer than docs).
- nrjames 10y ago
  I agree with the example apps. Some annotated source would be great, too. Something similar to the way dc.js annotates this example: https://dc-js.github.io/dc.js/docs/stock.html https://dc-js.github.io/dc.js/docs/stock.html
  - dumindunuwan 10y ago
    +1 for usinf dc.js type examples. I wished many times "Rust by example" could follow this type of detailed explanations and complex examples.
- threeseed 10y ago
  Personally I think Rust should take this one step further. Actually build templates into the platform itself. For example one for creating a microservice complete with routes, test cases, JSON support etc. Another for a command line application. In languages with a steeper learning curve like Rust there needs to be more of an opinionated approach to teaching users.
  - bluejekyll 10y ago
    I'm not sure how valuable this type of thing really is. Templates tend to fall out of date, since they're not actively used, they're not actively updated to new practices. I've seen this with lots of templates in other languages. The libraries having excellent documentation and pointing to apps that are similarly implemented tends to be better maintained, IMO.
EugeneOZ 10y ago
> Rust should provide a solid, but basic IDE experience After using IntelliJ IDEA plugin [1] (works in free community version too), I don't understand what else people need :) Plugin is pretty powerful. Also Racer works great in VS Code and other editors. > Rust should have a lower learning curve Rust is easy enough to learn, the only issue is a steep start. After couple of months everything is not harder than JS and smart compiler actually makes me more and more lazy :) So I think only thing we need is books/articles to help people switch from other languages, to help them overstep initial difficulties. [1] https://github.com/intellij-rust/intellij-rust https://github.com/intellij-rust/intellij-rust
fixxer 10y ago
Awesome to see the learning curve addressed with such high priority. I like Rust and I'd like to use it more, but I generally lean on Go or C for writing anything that needs performance. I can't quite get past the awkward, fumbling stage with Rust. Go, on the other hand, was really easy to get acquainted with and not too substantial of an effort to get to strong expertise. I've been able to teach Go to junior devs with no background and hand off projects within a couple weeks. Rust is awesome, but fits in a very different bracket IMO.
- pcwalton 10y ago
  It's important to note that Go and C have very different design goals from Rust. Go was never designed to have zero-cost abstractions (garbage collection being the most obvious outcome of this, but there are many others), and it has a runtime. C was never designed for safety and security, memory safety or otherwise. In short, Go sacrifices performance and C sacrifices safety, while Rust's goal is to sacrifice neither. Addressing the learning curve of Rust is important, but we aren't going to be able to do it by adopting concepts from Go or C. By and large, they just don't apply.
  - cbHXBY1D 10y ago
    If syntax isn't going to be changed, is that really addressing the learning curve of the language? Edit: I'm going to answer my own question here: yes. I just sometimes think Rust is a victim of its own success when people expect to learn Rust quickly because they learned Python in two days. No one expects to master C++ in a weekend.
  - yazaddaruvala 10y ago
    What are your thought on making `rustc` poly-lingual? Ideally, all libraries (i.e. should be written by experts) are written in Rust, but applications are allowed to be written in RustScript. RustScript would be optimized for lower learning curve. example[0]: - No `unsafe` allowed. - Everything is implicitly an `Arc<_>`. - All numerics are BigNum. - etc. This is inspired by the popularity of using Rust within other languages, like Ruby. The way this would differ from using another language: All the Rust tooling would be the same. Realistically it would just be a different parser for the Rust AST. Therefore no memory layout issues, or FFI involved. Like syntax-sugar to the extreme, the compiler (except the parser) wouldn't even know the difference. [0] I'm just listing simplifications, regardless of if they are a good idea.
sotojuan 10y ago
Really nice! I try to learn as little languages at the same time as possible so sadly I have no time for Rust at the moment, but it looks like it'll only get better.
cm3 10y ago
> Rust should integrate easily with C++ code The day that Rust manages to have always up to date Qt bindings that do not force you to make compromises compared to the C++ API, I think the C++ support will be at a comfortable level. Right now there are fresh efforts in the Rust and Haskell camps to solve this cleanly in a modern way. It would certainly help if the consumption of C++ APIs via llvm (which is used a lot byt Rust) was made a first class feature like you can import and export C APIs. Exporting C++ classes is a whole different story and may not map in any reasonable way to Rust modules or crates.
- bch 10y ago
  I'm ignorant of Rusts ABI/requirements, but can the C ABI be used as a lingua franca, or are there necessary facilities that are unsupportable there?
  - dikaiosune 10y ago
    FFI through a C ABI is how Rust <-> C++ currently works, but IIUC it's quite limiting when one might want to make use of C++ specific features. Especially important when a given C++ project doesn't have a fully-featured C API, or any C API at all.
  - whyever 10y ago
    There is no general C++ ABI, the ABI depends on the compiler and the standard library.
coherentpony 10y ago
I'd also like to see a push towards applications in scientific computing.
- cm3 10y ago
  Which shouldn't be hard since most scientific libraries rely on a standard body of Fortran code being reused underneath. The nice bits are the interactive development environment, or visual repl if you will, and Rust could reuse the efforts of Servo here to make something shiny and comfortable that is easier to get running than existing solutions on many platforms.
- synparb 10y ago
  First class multi-dimensional arrays with natural indexing syntax would be a huge draw. You get that in Numpy, Julia, Fortran and it is extremely powerful in terms of expressing the types of operations that are common across many scientific domains.
joshmarlow 10y ago
I would love to see Rust with a REPL. I use Python professionally a lot and have done a fair amount of OCaml in my spare time and both have excellent REPls in the form of `ipython` and `coretop`. Quick experiments with auto-complete is incredibly helpful for exploring a language. That's the only thing I really miss from those languages; when I want to wrap my head around a bit of syntax or a library feature in Rust, I build out a quick little experiment and see if it compiles and behaves as I expect it. With a good enough REPL, that's unneeded.
- Cyph0n 10y ago
  Scala does this extremely well too. Not sure whether or not a snippet will work? Run 'sbt console' and you're in a REPL with all of your code imported.
  - joshmarlow 10y ago
    Something like `cargo shell` or `cargo repl` that automatically imports whatever crate you happen to be working in would be fantastic. If you had something like that, I imagine you could probably write a Kernel for Jupyter which would be a huge win.
- manaskarekar 10y ago
  Although not exactly a REPL, the rust playground has proven very useful to me for similar purposes. Of course, you need to be online. https://play.rust-lang.org/ https://play.rust-lang.org/
- leshow 10y ago
  coming from haskell too, i missed this. ghci is really fantastic.
- bjz_ 10y ago
  I heard a while back that there was some work going into an interpreter for rust's mid-level IR (MIR), with the intention being to support a REPL. Not sure how that is going though.
geodel 10y ago
Overall it looks good. When I look at this : "Production use measures our design success; it's the ultimate reality check. Rust takes a unique stance on a number of tradeoffs, which we believe to position it well for writing fast and reliable software. The real test of those beliefs is people using Rust to build large, production systems, on which they're betting time and money." I see a little bit of haste towards production use. From 'Rust 1.0 is out just last year' to 'We really need successful production use', It does some to be a push from management to justify continued investment in Rust project.
- brson 10y ago
  We want rust to be successful and that means being adopted and used. It has nothing to do with management and justifying investing in rust. We are fortunate that Mozilla invests in rust to use rust and is currently very happy doing so.
- deleted 10y ago
  [deleted]
- aturon 10y ago
  The intent wasn't to say that we should be seeing big production use right this second, but rather to set out an overall "north star" for work on Rust. The investments in Rust today should be made with an eye toward driving or enabling production use in the future. I've updated the RFC to clarify this; thanks for the comment!
zzzcpan 10y ago
Focus on high-performance servers, async I/O, C integration is very promising. These are Go's weak points, could become a good alternative and a direct competition for Go.
- wahern 10y ago
  Care to elaborate on Go having weak async I/O support?
  - Scarbutt 10y ago
    It doesn't have it, Go uses a different concurrency model.
    - wahern 10y ago
      I manage a Lua framework that wraps Linux epoll, BSD kqueue, and Solaris Ports. Lua provides asymmetric coroutines, which the framework uses as logical "threads" for execution state. A Lua coroutine is a just a couple hundred bytes of state, likely smaller than a JavaScript/NodeJS closure all things considered, though slightly larger than a Lua closure. Lua also has very clean and elegant bindings to C. Lua is designed to be implemented in strict ISO C, yet also to make the C API a first-class citizen--not a hack around the VM like Python, Ruby, etc. The one caveat to this equivalence is coroutines--when a coroutine yields and resumes, it can't revive any C invocation frames (e.g. when Lua calls C calls Lua). So the C API to invoke a Lua routine can take a callback and cookie. If the VM yields and then resumes a coroutine across a C API boundary, the "return" from the Lua routine invocation happens by invoking the C callback. (See lua_callk in the manual.) From the perspective of C, as well as the kernel, this is a classic asynchronous I/0 pattern. From the perspective of Lua-script code, everything is transparent. I take it that because Go implements light-weight threads (goroutines, which is likely a pun on coroutines) you do not perceive it as offering async I/O. And yet from the perspective of the implementation as well as the kernel it's classic async I/O using epoll or kqueue, whether goroutines are bound to a single CPU core or not. The send and receive operations on a Go "channel" are very similar to the resume and yield operations of classic routines, and semantically identical in the context of async I/O programming (because with both goroutines and async I/O there are no guarantees about the order of resumption). Do you equate async I/O with callback-style programming? Do you think callback-style is somehow intrinsically less costly in terms of CPU or memory? I would dispute both of those contentions.
leshow 10y ago
Awesome. I have used Iron a few times to write small web services, but I can't wait for Rust to really have a strong story for the backend. If that happens it'll be the first language I reach for whenever I need to write a backend. I think it has a lot of great bonuses already. It's language ergonomics are that of a high-level language, yet it is extremely fast, and I can be very confident in my code if it compiles. Rust is one of my favorite languages, keep up the great work guys.
- vvanders 10y ago
  Yup, happy to see everything on the list. If one thing more than any stands out it's Rust's commitment not just to building a language but building an incredible community. With how seriously the release processes are being taken to the way new people are welcomed. Serious kudos, I know it's not the most technically engaging work but it makes a huge difference.
  - sjellis 10y ago
    Yes, as far I can tell, Rust is probably (pun intended) the gold standard in these areas. I only looked at Rust briefly, because the language itself felt too complex for my simple needs, but I was hugely impressed by how much concern and effort the core team seem to put into every aspect of the developer experience. The only other group that I know with that level of focus is the .NET people at Microsoft.
- berntb 10y ago
  Are you saying that Rust, a system programming language, can compete with the scripting languages in speed of developing features?! Or are you saying that it is a pleasure to use, so you'll use it for smaller backends where development speed isn't that critical? (Asking, not flaming. :-) )
  - cccooohn 10y ago
    the goal of 2017 "robust, high-scale servers" is maybe for this. scripts have fast developing speed,but are not always robust,high-scale,specially for those backend services developed by many developers,here are fields of java,go,.net,even c++.a language with safety,high performance,low resource consumtion is strong competitor.languages with GC such as JAVA are resource monsters,specially when there are unlimited microservices running simultaneously
rjammala 10y ago
One way to improve productivity of Rust with respect to the learning curve is to add more screencasts/tutorials to http://intorust.com http://intorust.com I found the existing ones very helpful and instructive.
- dj-wonk 10y ago
  Thanks, I'm watching now. I recommend it. "The primary author ... and the narrator on the screencasts, is Nicholas Matsakis ... Niko has been involved in Rust since 2011 and is a member of the Rust core team as well as the leader of the language and compiler teams"
dj-wonk 10y ago
Re: "Here are some strategies we might take to lower the learning curve: ... Improved docs. While the existing Rust book has been successful, we've learned a lot about teaching Rust, and there's a rewrite in the works. The effort is laser-focused on the key areas that trip people up today (ownership, modules, strings, errors)." Yes, please. I get better every day with Rust. I'd ask that the docs on lifetimes be improved with more elaboration on the ideas and more examples. Frankly, I still find the details confusing, so I can't offer more particulars right now.
dysfunctor 10y ago
Still no mention of standardization of a "systems language" that's served off a platform known to censor and manipulate... Klabnik and others have lashed out at people in the past over political ramblings, github has been known to engage in political correctness and majority shaming, ugh. Why on earth do people trust Rust at all? Without a standardized specification there's absolutely no good reason to trust mozilla code, and there's no "correct" way to work on a more properly FOSS implementation since they're essentially just making it up as they go along. I fear that rust will suffer a Java death, where some of the brightest engineers are conned into working on something people will come to detest later on. From a langtheory perspective, rust is one of the most backwards, mixed up, kludgy languages to come to light recently but it's ultimately a moot point since most languages are terrible anyways once you get to know them. C++ already works, why don't we just improve on whatever's lacking? Rust astroturfers like pcwalton and klabnik can't wait to explain why go isn't competing with rust since they didn't opt for zero cost abstractions in some cases and instead chose to have a coherent language, but go GC is now down to under 5ms, and while I'm honestly not a fan of Google any more than mozilla, I gotta respect the visionaries behind go, the stick-to-it-iveness of the design team, and the relentless performance increases over the past couple years. I'd rather write lisp or Julia or ruby or something fun than most other junk languages, but watching the front lines of allegedly performant languages always gives me ideas on how to make my own projects faster or more efficient.
- babyrainbow 10y ago
  >From a langtheory perspective, rust is one of the most backwards, mixed up, kludgy languages to come to light recently.. Would really like to know more about this. It is not very often that you come across Rust criticism in this forum. >C++ already works, why don't we just improve on whatever's lacking? But can it done in such a way that it works with the rest of the language and standard library?
  - sssilver 10y ago
    C++ at this point can only be principally improved by drastically reducing the language, and that will never happen. Ever.
ifhs 10y ago
It's amazing how much the rust team has nailed it. they know exactly what the problems are. I do not know of any other team as talented as rust. Then language is also quiet brilliant. I have started rewriting all my code in rust the days. It just makes sense.
petters 10y ago
My personal code base is C++/cmake and Python. It would be really nice with a way to slowly start writing code in Rust instead.
- azdle 10y ago
  You might be interested in this post about using rust with python: https://blog.sentry.io/2016/10/19/fixing-python-performance-with-rust.html https://blog.sentry.io/2016/10/19/fixing-python-performance-...
agentgt 10y ago
For what it's worth I hope serde or whatever default serializers are improved. I had some serious issues trying to combine libraries because of serde changing too much. Albeit this was about a year ago so it probably is fixed. Second it would be nice to see some best practices not just for libraries but application development. What to do and what not to do. Maybe a cookbook or even... design patterns. I had a hard time trying to figure out if I should embrace closures or go traits (at the time closures were not working as well so maybe this is not an issue either).
- steveklabnik 10y ago
  We have already landed the underlying things Serde needs to be better in nightly Rust, and it should be stable soon. I would love to see such a thing as well; I wonder if we're not quite old enough to have said patterns really gel yet. We'll see if someone comes up with something.
serge2k 10y ago
> Rust should have a lower learning curve Rust should have a pleasant edit-compile-debug cycle Rust should provide a solid, but basic IDE experience I know the list isn't necessarily prioritized, but these 3 feel backwards. A good IDE will provide can help facilitate easier edit/compile/debug cycle which makes learning the language faster because it's cheaper (time wise) to figure things out.
- steveklabnik 10y ago
  They're not ordered.
unfamiliar 10y ago
>We asked both current and potential users what most stands in the way of their using Rust, and got some pretty clear answers: >1 in 4: learning curve >1 in 7: lack of libraries >1 in 9: general “maturity” concerns >1 in 19: lack of IDEs (1 in 4 non-users) >1 in 20: compiler performance >None of these obstacles is directly about the core language or std; people are generally happy with what the language offers today. Instead, the connecting theme is productivity—how quickly can I start writing real code? bring up a team? prototype and iterate? debug my code? And so on. I don't really see how this conclusion was reached from that data. The "learning curve" is almost certainly a reflection of the language being a little esoteric and the demands of the borrow checker. And "lack of libraries" is partly a comment on the ecosystem, but also partly shows that std is obviously lacking for some needs. Finally, "general maturity concerns" refers to worries that the language or std will keep changing, as is assumed they have not been perfected yet. Those are the top 3 concerns and to me, both seem to relate directly to the language or standard library.
- bpicolo 10y ago
  I also don't think library maturity is necessarily the only problem that makes working with libraries difficult at time. You can get burned pretty easily by someone not having e.g. Send + Sync on an essential library data structure. (Though maybe there's a way around it other than forking?) That metadata ends up being very important
  - burntsushi 10y ago
    Send + Sync are automatically implemented for a type X if all of X's constituents are also Send + Sync. In practice, this means that unless you're using unsafe code, Cell/RefCell or Rc, then the Right Thing will just happen automatically. If you are using Cell/RefCell/Rc/unsafe, then you need to think carefully about your synchronization story anyway, so it's typically not something you just forget to do. For more details, see: https://doc.rust-lang.org/std/marker/trait.Sync.html https://doc.rust-lang.org/std/marker/trait.Sync.html and https://doc.rust-lang.org/std/marker/trait.Send.html https://doc.rust-lang.org/std/marker/trait.Send.html
- 10y ago
Dowwie 10y ago
Idiomatic Rust guides would be very helpful

2017 Rust Roadmap

332 points by muizelaar 10y ago

I read through the Rust book, and the problem I was having with it and the other docs is that it was hard to map the Rust concepts with what actually runs when it is compiled. For a language that touts "uncompromising performance", it was difficult for me to find performance characteristics of the underlying abstractions and std library (for example, are algebraic data structures just tagged unions or does the compiler do more fancy things with them? What about iterators?). I'd really like to see a "Rust for C/C++ devs" guide that helps you figure out if you were using [some C++ feature] the way to get that behavior/performance with idiomatic Rust. Another thing that is still tricky for me is figuring out when I should use 'unsafe' blocks in my code. Is it to be avoided if at all possible, or should I go there any time the 'safe' part of the language is making it difficult to express what I want? The meme that Rust is C++ without SegFaults and or race conditions is a bit misleading since the actual guarantee is that you don't get SegFaults or Race conditions outside of Unsafe blocks, and any nontrivial project will make use of unsafe blocks.

wyldfire 10y ago
> any nontrivial project will make use of unsafe blocks. Sure! But that's okay. Just don't use 'quantity of unsafe blocks' as a metric of quality and you'll be all set. Think of it like so: don't use it until you have to and try not to have to. For me, that means consulting experts on IRC (etc), "How can I express this goal in idiomatic rust?" No different from learning C/C++ for the first time, IMO. And if no good way exists you may have to use unsafe blocks. Unsafe blocks aren't bad, just like #pragma-disable-this-warning and --static-checker-I-did-it-this-way-by-design aren't bad. They mean that you've thought critically about the pros and cons and you are going into this decision well aware of the risk. On the flip side they should be the first blocks to closely examine in the face of failures like segfaults/races/etc.
- cmrx64 10y ago
  > > any nontrivial project will make use of unsafe blocks. I don't think that's actually true? Most projects make use of no unsafe outside of stdlib and a handful of crates.io crates.
  - vvanders 10y ago
    About the only time I end up using it is for ffi and uninitialized arrays on the stack.
  - mitchmindtree 10y ago
    This has been my experience also. I've written at least 40kloc of rust over the past couple years (including complex graphs with cycles, low-level DSP) and I could probably count the number of unsafe blocks I've needed on one hand. edit: This is not counting FFI though.
    - chrismorgan 10y ago
      Excluding FFI I might just be able to count the number on unsafe blocks I’ve needed on one hand. But honesty compels me to declare that for reasons of performance micro-optimisation, I’ve written a lot more.
    - DennisP 10y ago
      How do you handle cycles? I've seen discussions on places like /r/rust where people didn't seem to have any pleasant answers.
      - mitchmindtree 10y ago
        I tend to use petgraph[1] when I need a graph-like data structure (the only time I've needed cycles). Super fast, distinguishes `Node`s from `Edge`s, lots of useful items for different kinds of traversal. [1]: https://github.com/bluss/petgraph https://github.com/bluss/petgraph
  - sidlls 10y ago
anuragsoni 10y ago
I am not sure if you have come across this "Rust tutorial for c/c++ programmers" https://github.com/nrc/r4cppp https://github.com/nrc/r4cppp but I found it to be nice when I was first exploring Rust (I had prior experience with C++). I haven't had to resort to "unsafe" blocks in the Rust I have written so far but "ffi" is one use case for unsafe blocks. Another resource that I have yet to read is "https://doc.rust-lang.org/nomicon/" https://doc.rust-lang.org/nomicon/" which seems to explain how to write unsafe Rust code.
dikaiosune 10y ago
Is there an equivalent guide to the compile-time representation of important constructs for those trying to learn C/C++? I haven't seen anything like that and it seems like most devs in that realm instead rely on experience and tribal knowledge (which is, AFAICT, how it often works in Rust-land right now). I agree it'd be great for Rust to have clearer official docs about some of these things, but it doesn't seem to me like this is readily available for most languages or runtimes. Re: unsafe, I think that's tough. My personal feeling is that many of Rust's selling points rely on minimizing the use of unsafe (i.e. limiting segfault-relevant portions of the code), and that there are frequently ways to make things work and also make them fast without using unsafe. What's an example where you found yourself thinking about using unsafe instead of a more complex safe construct? (Somewhat related to this, and especially for anyone reading who might try Rust, I cannot recommend getting on IRC strongly enough. The Rust IRC channels are by and large incredibly friendly and helpful, and for better or worse that's where a lot of the knowledge in the community is currently collected, not as much SO or blogs)
- cheepin 10y ago
  > Is there an equivalent guide to the compile-time representation of important constructs for those trying to learn C/C++? Definitely. It was taught in school and there's pretty good guides for it online (maybe not caught up to c++11 and beyond, but the fundamentals are there). You're right that it is not readily available for most languages, but when you need to get serious about performance you either are going to have a guide or spend a lot of time looking at assembly/bytecode. To be fair, I'd probably still have to inspect generated code sometimes, but it's nice to have good instincts for how things run to guide your design/implementation so you can spend less time looking at assembly. http://www.agner.org/optimize/optimizing_cpp.pdf http://www.agner.org/optimize/optimizing_cpp.pdf
  - dikaiosune 10y ago
    I definitely haven't seen anything as comprehensive as the linked PDF for Rust (although that shouldn't be surprising given the extreme thoroughness of that guide and the age of C++). Probably a good project! When doing very performance sensitive things in Rust, I usually find myself asking questions a lot on IRC and looking at disassembly in perf. To answer some specific examples you cited above: I'm pretty sure that enums are (almost?) always equivalent to tagged unions. If you have an enum which doesn't contain any data, then I believe it's representation is just the tag. Iterators are just structs with methods, the various generic functions they implement are monomorphized and then optimized by LLVM.
leshow 10y ago
Most crates don't make use of unsafe, the stuff that I see that does use unsafe is mostly either embedded applications or stuff like the std lib. And even if you do use unsafe, you can still use it to build 'safe' abstractions on top of. the idea is that your unsafe code is quarantined and abstracted, and you build on top of it. std::collections is a great example of this.
pcwalton 10y ago
> for example, are algebraic data structures just tagged unions They're tagged unions with no implicit heap allocations. I guess we should at least document that in the reference (though we don't want to overspecify, because we do some tricks in the compiler to try to avoid leaving space for the tag if we can). But I don't think it'd be a good idea to document this straight away in the book: the goal is to make Rust easy to pick up, and adding more information than necessary when introducing enums (which a lot of folks will only see for the first time in Rust) isn't going to do people any favors. > What about iterators? The documentation for Iter explains this pretty well, I think: https://doc.rust-lang.org/stable/std/iter/ https://doc.rust-lang.org/stable/std/iter/ It even shows the exact implementation of (basically) Range, to give you an idea. That said, it would probably be worth calling out that most iterators are guaranteed not to allocate. Note, though, that that isn't a hard-and-fast constraint that implementors of the trait have to abide by—you can make your own iterators and implement them however efficiently or inefficiently you like. > The meme that Rust is C++ without SegFaults and or race conditions is a bit misleading since the actual guarantee is that you don't get SegFaults or Race conditions outside of Unsafe blocks, and any nontrivial project will make use of unsafe blocks. They'll make use of unsafe blocks transitively, by using unsafe code in the standard library or well-tested crates. Think of these unsafe blocks as part of the compiler: you trust the compiler to generate correct machine code when you type "a + b", so likewise you trust the standard library to do the right thing when you say "HashMap::new()". It is not the case that most projects should use unsafe themselves everywhere: that usually just makes life harder. The primary exception is if you're binding to C code, in which unsafe is unavoidable.
- kalkin 10y ago
  Speaking of "guaranteed not to allocate", is there a way that you could express that in a type? Seems like that might be nice to have.
  - tatterdemalion 10y ago
    Not in Rust's type system. In a pure language, you could have some sort of "Heap" monad similar to the "IO" type in Haskell.
Manishearth 10y ago
> . Is it to be avoided if at all possible, or should I go there any time the 'safe' part of the language is making it difficult to express what I want? The main reasons to use unsafe code are when you're doing FFI and have to regrettably talk to C/++ libraries, or when designing new abstractions with a safe API boundary. It's tricky to ensure that the former is safe since you eventually have to trust C++ (but then, that's not Rust's fault). It's not hard to ensure that the latter is safe. Looking at a page of code and ensuring that it can't cause segfaults is a much easier task than doing it for the entire codebase. This is almost all the unsafe code out there. There's a bit of it used for doing manual optimizations. When Rust doesn't let you do what you want, often there are abstractions like RefCell that have a small cost that you can use (and they contribute to the overall safety). In case this happens in performance critical code, you can use unsafe again, but this is very rare. In Servo, for example, almost all of the unsafe code is of the first two kinds. I've been hacking on Servo for years and didn't write much unsafe code at all -- when I did, it had to do with talking to Spidermonkey, and even that was pretty rare. More recently I'm working on integrating Servo's style system into Firefox (which is C++), and only now have I been regularly writing unsafe code. Even for this project the unsafe code I'm writing abstracts away the inherent unsafety of Firefox's C++ so that others can talk to Firefox with safe Rust code. But many projects have no unsafe code at all. It's not that common to have unsafe code. > it was difficult for me to find performance characteristics of the underlying abstractions and std library (for example, are algebraic data structures just tagged unions or does the compiler do more fancy things with them? What about iterators?). Note that a C++ book won't help here for C++ too. What is a switch compiled down to? Does it use a jump table? :) But yeah, it would be nice to have a thing for this. I don't think it belongs in the official book, but it should exist :) ADTs are tagged unions. When non-nullable pointers are involved sometimes the tag is stored as a null pointer (e.g. `Option<Box<Foo>>` is a single pointer, and is None when null. Aside from that, nothing fancy. Iterators compile down to the equivalent for loops. I can't think of any stdlib iterator which implicitly allocates; they all operate on the stack. In general these are just zero-cost abstractions, they will compile down the the code you would have written with manual loops. This is a recurring theme with the stdlib and even crates from the ecosystem. "extra" costs for abstractions are eschewed in Rust and will often be documented when they exist. So as a rule of thumb assuming that a random abstraction doesn't have an overhead unless explicitly mentioned is good.
steveklabnik 10y ago
This is an area in which I haven't quite figured out how to communicate properly; I feel like I have a good understanding of how Rust maps to asm, but I don't know how to transfer that understanding to other people. I'll certainly be reading your link below, thanks for that!
- tmzt 10y ago
  Would an updated and expanded Rust for C++ Programmers make sense as a companion to the book with references to concepts in the book along with low-level details on data structures or implementation? It would nice to see that and Nomicon more closely related and fully up-to-date. It soulds like an informal "specification" of #[repr(c)] or #[repr(packed)] for common platforms would also be useful for FFI.
  - steveklabnik 10y ago
    Yeah it'd be great to have.
ezy 10y ago
> it was hard to map the Rust concepts with what actually runs when it is compiled. This. The primary reason to choose rust is performance -- that is, you want more advanced abstraction/safety capabilities than C++, and you want that with the same or better performance. And performance implies CPU cost and memory usage/layout control. There really isn't any point otherwise. Therefore, going into at least a little bit of detail on the idioms and performance impact of those idioms is important. Rust is a supposed to be a systems programming language to replace C, do not pretend it's as abstract as ML in the documentation. What throws me for a loop when learning Rust isn't high level details like the borrow checker or sum types, it's what is happening with cpu & memory[1]. When things are copied, when they aren't, how much do the std derives cost, matching cost, sum type storage cost, etc. Because while the semantics are similar to C++, they are not the same. And you don't have to go nuts specifying it (compilers will differ), but at least give a general understanding/hint of what to do and what to avoid. To be fair, the doc does have this scattered about, but it doesn't feel a priority (There are many things I've had to search the web for or ask on #rust, or just look at disassembly for). [1] To take an extremely simple example, RVA is something Rust supposedly does much more consistently than C++, thus returning a new struct by value to be placed wherever is idiomatic. However this isn't called out very clearly (the last time I checked) in the doc, and to a C programmer, it feels very wrong. Stuff like this is extremely important, otherwise we'd just ignore performance and use a JVM based language with the same (or better) abstraction features and a faster compiler. :-)

dikaiosune 10y ago

It's important to note that this is an RFC which has been proposed, and there's likely to be a good deal of discussion and revision before it's merged/adopted as the official 2017 roadmap. The conversation can be followed/joined/whatever here: https://github.com/rust-lang/rfcs/pull/1774 https://github.com/rust-lang/rfcs/pull/1774

collinmanderson 10y ago
"accordance with RFC 1728" - could they have chosen a naming scheme so their documents are not confused with the _real_ RFC's? Even RRFC 1728 would helpful. Or maybe just #1728?
- tatterdemalion 10y ago
  Lexical scope. You should assume an RFC cited in a Rust RFC is a Rust RFC, you're in the Rust RFC scope. If an IETF RFC is cited in a Rust RFC, it won't be ambiguous.
- Can_Not 10y ago
  Why do "the _real_ RFC's" have exclusive rights to that term?

kalmar 10y ago

This is a better link, as it will include the discussion: https://github.com/rust-lang/rfcs/pull/1774 https://github.com/rust-lang/rfcs/pull/1774

gravypod 10y ago

> 1 in 19: lack of IDEs (1 in 4 non-users) I expected that to be higher actually, but that's still the only reason I don't use the language. I've come to rely heavily on IDEs. Whether right or not it's a huge factor in my decision to wait for the language.

vvanders 10y ago
If that's the case I highly recommend giving VSCode a spin. With racer I've got solid code complete, goto def and docs. They've also been making leaps and bounds in terms of features so I can only imagine it improving even more.
raindev 10y ago
I've been writing Java in Vim from time to time for 3 years. Rust is much more pleasant to deal with in a plain text editor. I encourage you to give it a try.
unfamiliar 10y ago
What kind of IDE support do you typically use that isn't handled by a modern text editor (such as go to definition, variable renaming, find and replace, etc)? I'm starting to use CLion for my C++ work now, because "go to definition" is much more reliable than most editors can manage with C++ code, but I find that most of the fancy refactoring features like extracting functions or subclasses are not used often enough to be really useful.
- gravypod 10y ago
  The features I need are: - Refactoring Support (rename variable, class, function) - Code Folding - Automatic type checking - Automatic error detection (tells me when syntactical or other errors are made) - Built-in documentation loading/display on hover of cursor. - Same thing as above except with any documentation I add myself on a function. - Debugger with comment overlay of values (like PyCharm) - Dependency management/Building/Deploying all a *button* (not 10 commands) away - VCS integration - Automatic code formatting - Automatic code "cleaner" (change for (int i = 0; i < arr.length; i++) to an expanded loop for example) - Automatic import cleaning - Automatic project creation for basic use cases (console, GUI, maybe a web framework) - Change CWD/environment variable for running the program - GOTO definition - A Graphical User Interface (Graphical being the biggest requirement) Outside of all of those, there is a much much much more important feature: Auto Complete. A smart auto complete. An autocomplete that understands the type system and the function's return types. For instance if I am typing: String sub = someString. It shouldn't recommend "length()" as well as in the case of: String lengthStr = Integer.toString(someString. It should recommend things that return an integer. This needs to be fast and needs to be non-case-sensitive. Also, if I am typing Lis It should recommend List, ArrayList, etc in that order with the closest thing up front. It should also in the recommendation screen show documentation, a link to official documentation, and possibly an example of how to initialize/use the code. If something isn't imported and so it's not currently usable, if the user clicks enter or whatever on the auto-complete screen you should import it. If it has that, and has that working quickly, and has that working completely it's a "real" IDE in my book. That list is just "wants", this one thing is a "need" If I had that for rust, I'd switch over to rust as my main language. Anything that doesn't have something like that will never compete with Eclipse in ease-of-adoption in my book.

adamnemecek 10y ago

I would also suggest taking a page out of Apple's playbook and providing some official sample apps like https://developer.apple.com/library/content/navigation/#section=Resource%20Types&topic=Sample%20Code https://developer.apple.com/library/content/navigation/#sect.... Reading the books is one thing, but seeing the patterns actually used is another. You don't need as many as Apple, only a couple really, but make sure they are well written and straddle a couple of use cases. And like go crazy with the idioms, I want to see the most idiomatic Rust code. When learning a new platform, it's always frustrating having to hunt for good code. I actually find these similarly important as docs (maybe even more because I tend to reference good open source for much longer than docs).

nrjames 10y ago
I agree with the example apps. Some annotated source would be great, too. Something similar to the way dc.js annotates this example: https://dc-js.github.io/dc.js/docs/stock.html https://dc-js.github.io/dc.js/docs/stock.html
- dumindunuwan 10y ago
  +1 for usinf dc.js type examples. I wished many times "Rust by example" could follow this type of detailed explanations and complex examples.
threeseed 10y ago
Personally I think Rust should take this one step further. Actually build templates into the platform itself. For example one for creating a microservice complete with routes, test cases, JSON support etc. Another for a command line application. In languages with a steeper learning curve like Rust there needs to be more of an opinionated approach to teaching users.
- bluejekyll 10y ago
  I'm not sure how valuable this type of thing really is. Templates tend to fall out of date, since they're not actively used, they're not actively updated to new practices. I've seen this with lots of templates in other languages. The libraries having excellent documentation and pointing to apps that are similarly implemented tends to be better maintained, IMO.

EugeneOZ 10y ago

> Rust should provide a solid, but basic IDE experience After using IntelliJ IDEA plugin [1] (works in free community version too), I don't understand what else people need :) Plugin is pretty powerful. Also Racer works great in VS Code and other editors. > Rust should have a lower learning curve Rust is easy enough to learn, the only issue is a steep start. After couple of months everything is not harder than JS and smart compiler actually makes me more and more lazy :) So I think only thing we need is books/articles to help people switch from other languages, to help them overstep initial difficulties. [1] https://github.com/intellij-rust/intellij-rust https://github.com/intellij-rust/intellij-rust

fixxer 10y ago

Awesome to see the learning curve addressed with such high priority. I like Rust and I'd like to use it more, but I generally lean on Go or C for writing anything that needs performance. I can't quite get past the awkward, fumbling stage with Rust. Go, on the other hand, was really easy to get acquainted with and not too substantial of an effort to get to strong expertise. I've been able to teach Go to junior devs with no background and hand off projects within a couple weeks. Rust is awesome, but fits in a very different bracket IMO.

pcwalton 10y ago
It's important to note that Go and C have very different design goals from Rust. Go was never designed to have zero-cost abstractions (garbage collection being the most obvious outcome of this, but there are many others), and it has a runtime. C was never designed for safety and security, memory safety or otherwise. In short, Go sacrifices performance and C sacrifices safety, while Rust's goal is to sacrifice neither. Addressing the learning curve of Rust is important, but we aren't going to be able to do it by adopting concepts from Go or C. By and large, they just don't apply.
- cbHXBY1D 10y ago
  If syntax isn't going to be changed, is that really addressing the learning curve of the language? Edit: I'm going to answer my own question here: yes. I just sometimes think Rust is a victim of its own success when people expect to learn Rust quickly because they learned Python in two days. No one expects to master C++ in a weekend.
- yazaddaruvala 10y ago
  What are your thought on making `rustc` poly-lingual? Ideally, all libraries (i.e. should be written by experts) are written in Rust, but applications are allowed to be written in RustScript. RustScript would be optimized for lower learning curve. example[0]: - No `unsafe` allowed. - Everything is implicitly an `Arc<_>`. - All numerics are BigNum. - etc. This is inspired by the popularity of using Rust within other languages, like Ruby. The way this would differ from using another language: All the Rust tooling would be the same. Realistically it would just be a different parser for the Rust AST. Therefore no memory layout issues, or FFI involved. Like syntax-sugar to the extreme, the compiler (except the parser) wouldn't even know the difference. [0] I'm just listing simplifications, regardless of if they are a good idea.

sotojuan 10y ago

Really nice! I try to learn as little languages at the same time as possible so sadly I have no time for Rust at the moment, but it looks like it'll only get better.

cm3 10y ago

> Rust should integrate easily with C++ code The day that Rust manages to have always up to date Qt bindings that do not force you to make compromises compared to the C++ API, I think the C++ support will be at a comfortable level. Right now there are fresh efforts in the Rust and Haskell camps to solve this cleanly in a modern way. It would certainly help if the consumption of C++ APIs via llvm (which is used a lot byt Rust) was made a first class feature like you can import and export C APIs. Exporting C++ classes is a whole different story and may not map in any reasonable way to Rust modules or crates.

bch 10y ago
I'm ignorant of Rusts ABI/requirements, but can the C ABI be used as a lingua franca, or are there necessary facilities that are unsupportable there?
- dikaiosune 10y ago
  FFI through a C ABI is how Rust <-> C++ currently works, but IIUC it's quite limiting when one might want to make use of C++ specific features. Especially important when a given C++ project doesn't have a fully-featured C API, or any C API at all.
- whyever 10y ago
  There is no general C++ ABI, the ABI depends on the compiler and the standard library.

coherentpony 10y ago

I'd also like to see a push towards applications in scientific computing.

cm3 10y ago
Which shouldn't be hard since most scientific libraries rely on a standard body of Fortran code being reused underneath. The nice bits are the interactive development environment, or visual repl if you will, and Rust could reuse the efforts of Servo here to make something shiny and comfortable that is easier to get running than existing solutions on many platforms.
synparb 10y ago
First class multi-dimensional arrays with natural indexing syntax would be a huge draw. You get that in Numpy, Julia, Fortran and it is extremely powerful in terms of expressing the types of operations that are common across many scientific domains.

joshmarlow 10y ago

I would love to see Rust with a REPL. I use Python professionally a lot and have done a fair amount of OCaml in my spare time and both have excellent REPls in the form of `ipython` and `coretop`. Quick experiments with auto-complete is incredibly helpful for exploring a language. That's the only thing I really miss from those languages; when I want to wrap my head around a bit of syntax or a library feature in Rust, I build out a quick little experiment and see if it compiles and behaves as I expect it. With a good enough REPL, that's unneeded.

Cyph0n 10y ago
Scala does this extremely well too. Not sure whether or not a snippet will work? Run 'sbt console' and you're in a REPL with all of your code imported.
- joshmarlow 10y ago
  Something like `cargo shell` or `cargo repl` that automatically imports whatever crate you happen to be working in would be fantastic. If you had something like that, I imagine you could probably write a Kernel for Jupyter which would be a huge win.
manaskarekar 10y ago
Although not exactly a REPL, the rust playground has proven very useful to me for similar purposes. Of course, you need to be online. https://play.rust-lang.org/ https://play.rust-lang.org/
leshow 10y ago
coming from haskell too, i missed this. ghci is really fantastic.
bjz_ 10y ago
I heard a while back that there was some work going into an interpreter for rust's mid-level IR (MIR), with the intention being to support a REPL. Not sure how that is going though.

geodel 10y ago

Overall it looks good. When I look at this : "Production use measures our design success; it's the ultimate reality check. Rust takes a unique stance on a number of tradeoffs, which we believe to position it well for writing fast and reliable software. The real test of those beliefs is people using Rust to build large, production systems, on which they're betting time and money." I see a little bit of haste towards production use. From 'Rust 1.0 is out just last year' to 'We really need successful production use', It does some to be a push from management to justify continued investment in Rust project.

brson 10y ago
We want rust to be successful and that means being adopted and used. It has nothing to do with management and justifying investing in rust. We are fortunate that Mozilla invests in rust to use rust and is currently very happy doing so.
deleted 10y ago
[deleted]
aturon 10y ago
The intent wasn't to say that we should be seeing big production use right this second, but rather to set out an overall "north star" for work on Rust. The investments in Rust today should be made with an eye toward driving or enabling production use in the future. I've updated the RFC to clarify this; thanks for the comment!

zzzcpan 10y ago

Focus on high-performance servers, async I/O, C integration is very promising. These are Go's weak points, could become a good alternative and a direct competition for Go.

wahern 10y ago
Care to elaborate on Go having weak async I/O support?
- Scarbutt 10y ago
  It doesn't have it, Go uses a different concurrency model.
  - wahern 10y ago
    I manage a Lua framework that wraps Linux epoll, BSD kqueue, and Solaris Ports. Lua provides asymmetric coroutines, which the framework uses as logical "threads" for execution state. A Lua coroutine is a just a couple hundred bytes of state, likely smaller than a JavaScript/NodeJS closure all things considered, though slightly larger than a Lua closure. Lua also has very clean and elegant bindings to C. Lua is designed to be implemented in strict ISO C, yet also to make the C API a first-class citizen--not a hack around the VM like Python, Ruby, etc. The one caveat to this equivalence is coroutines--when a coroutine yields and resumes, it can't revive any C invocation frames (e.g. when Lua calls C calls Lua). So the C API to invoke a Lua routine can take a callback and cookie. If the VM yields and then resumes a coroutine across a C API boundary, the "return" from the Lua routine invocation happens by invoking the C callback. (See lua_callk in the manual.) From the perspective of C, as well as the kernel, this is a classic asynchronous I/0 pattern. From the perspective of Lua-script code, everything is transparent. I take it that because Go implements light-weight threads (goroutines, which is likely a pun on coroutines) you do not perceive it as offering async I/O. And yet from the perspective of the implementation as well as the kernel it's classic async I/O using epoll or kqueue, whether goroutines are bound to a single CPU core or not. The send and receive operations on a Go "channel" are very similar to the resume and yield operations of classic routines, and semantically identical in the context of async I/O programming (because with both goroutines and async I/O there are no guarantees about the order of resumption). Do you equate async I/O with callback-style programming? Do you think callback-style is somehow intrinsically less costly in terms of CPU or memory? I would dispute both of those contentions.

leshow 10y ago

Awesome. I have used Iron a few times to write small web services, but I can't wait for Rust to really have a strong story for the backend. If that happens it'll be the first language I reach for whenever I need to write a backend. I think it has a lot of great bonuses already. It's language ergonomics are that of a high-level language, yet it is extremely fast, and I can be very confident in my code if it compiles. Rust is one of my favorite languages, keep up the great work guys.

vvanders 10y ago
Yup, happy to see everything on the list. If one thing more than any stands out it's Rust's commitment not just to building a language but building an incredible community. With how seriously the release processes are being taken to the way new people are welcomed. Serious kudos, I know it's not the most technically engaging work but it makes a huge difference.
- sjellis 10y ago
  Yes, as far I can tell, Rust is probably (pun intended) the gold standard in these areas. I only looked at Rust briefly, because the language itself felt too complex for my simple needs, but I was hugely impressed by how much concern and effort the core team seem to put into every aspect of the developer experience. The only other group that I know with that level of focus is the .NET people at Microsoft.
berntb 10y ago
Are you saying that Rust, a system programming language, can compete with the scripting languages in speed of developing features?! Or are you saying that it is a pleasure to use, so you'll use it for smaller backends where development speed isn't that critical? (Asking, not flaming. :-) )
- cccooohn 10y ago
  the goal of 2017 "robust, high-scale servers" is maybe for this. scripts have fast developing speed,but are not always robust,high-scale,specially for those backend services developed by many developers,here are fields of java,go,.net,even c++.a language with safety,high performance,low resource consumtion is strong competitor.languages with GC such as JAVA are resource monsters,specially when there are unlimited microservices running simultaneously

rjammala 10y ago

One way to improve productivity of Rust with respect to the learning curve is to add more screencasts/tutorials to http://intorust.com http://intorust.com I found the existing ones very helpful and instructive.

dj-wonk 10y ago
Thanks, I'm watching now. I recommend it. "The primary author ... and the narrator on the screencasts, is Nicholas Matsakis ... Niko has been involved in Rust since 2011 and is a member of the Rust core team as well as the leader of the language and compiler teams"

dj-wonk 10y ago

Re: "Here are some strategies we might take to lower the learning curve: ... Improved docs. While the existing Rust book has been successful, we've learned a lot about teaching Rust, and there's a rewrite in the works. The effort is laser-focused on the key areas that trip people up today (ownership, modules, strings, errors)." Yes, please. I get better every day with Rust. I'd ask that the docs on lifetimes be improved with more elaboration on the ideas and more examples. Frankly, I still find the details confusing, so I can't offer more particulars right now.

dysfunctor 10y ago

Still no mention of standardization of a "systems language" that's served off a platform known to censor and manipulate... Klabnik and others have lashed out at people in the past over political ramblings, github has been known to engage in political correctness and majority shaming, ugh. Why on earth do people trust Rust at all? Without a standardized specification there's absolutely no good reason to trust mozilla code, and there's no "correct" way to work on a more properly FOSS implementation since they're essentially just making it up as they go along. I fear that rust will suffer a Java death, where some of the brightest engineers are conned into working on something people will come to detest later on. From a langtheory perspective, rust is one of the most backwards, mixed up, kludgy languages to come to light recently but it's ultimately a moot point since most languages are terrible anyways once you get to know them. C++ already works, why don't we just improve on whatever's lacking? Rust astroturfers like pcwalton and klabnik can't wait to explain why go isn't competing with rust since they didn't opt for zero cost abstractions in some cases and instead chose to have a coherent language, but go GC is now down to under 5ms, and while I'm honestly not a fan of Google any more than mozilla, I gotta respect the visionaries behind go, the stick-to-it-iveness of the design team, and the relentless performance increases over the past couple years. I'd rather write lisp or Julia or ruby or something fun than most other junk languages, but watching the front lines of allegedly performant languages always gives me ideas on how to make my own projects faster or more efficient.

babyrainbow 10y ago
>From a langtheory perspective, rust is one of the most backwards, mixed up, kludgy languages to come to light recently.. Would really like to know more about this. It is not very often that you come across Rust criticism in this forum. >C++ already works, why don't we just improve on whatever's lacking? But can it done in such a way that it works with the rest of the language and standard library?
- sssilver 10y ago
  C++ at this point can only be principally improved by drastically reducing the language, and that will never happen. Ever.

ifhs 10y ago

It's amazing how much the rust team has nailed it. they know exactly what the problems are. I do not know of any other team as talented as rust. Then language is also quiet brilliant. I have started rewriting all my code in rust the days. It just makes sense.

petters 10y ago

My personal code base is C++/cmake and Python. It would be really nice with a way to slowly start writing code in Rust instead.

azdle 10y ago
You might be interested in this post about using rust with python: https://blog.sentry.io/2016/10/19/fixing-python-performance-with-rust.html https://blog.sentry.io/2016/10/19/fixing-python-performance-...

agentgt 10y ago

For what it's worth I hope serde or whatever default serializers are improved. I had some serious issues trying to combine libraries because of serde changing too much. Albeit this was about a year ago so it probably is fixed. Second it would be nice to see some best practices not just for libraries but application development. What to do and what not to do. Maybe a cookbook or even... design patterns. I had a hard time trying to figure out if I should embrace closures or go traits (at the time closures were not working as well so maybe this is not an issue either).

steveklabnik 10y ago
We have already landed the underlying things Serde needs to be better in nightly Rust, and it should be stable soon. I would love to see such a thing as well; I wonder if we're not quite old enough to have said patterns really gel yet. We'll see if someone comes up with something.

serge2k 10y ago

> Rust should have a lower learning curve Rust should have a pleasant edit-compile-debug cycle Rust should provide a solid, but basic IDE experience I know the list isn't necessarily prioritized, but these 3 feel backwards. A good IDE will provide can help facilitate easier edit/compile/debug cycle which makes learning the language faster because it's cheaper (time wise) to figure things out.

steveklabnik 10y ago
They're not ordered.

unfamiliar 10y ago

>We asked both current and potential users what most stands in the way of their using Rust, and got some pretty clear answers: >1 in 4: learning curve >1 in 7: lack of libraries >1 in 9: general “maturity” concerns >1 in 19: lack of IDEs (1 in 4 non-users) >1 in 20: compiler performance >None of these obstacles is directly about the core language or std; people are generally happy with what the language offers today. Instead, the connecting theme is productivity—how quickly can I start writing real code? bring up a team? prototype and iterate? debug my code? And so on. I don't really see how this conclusion was reached from that data. The "learning curve" is almost certainly a reflection of the language being a little esoteric and the demands of the borrow checker. And "lack of libraries" is partly a comment on the ecosystem, but also partly shows that std is obviously lacking for some needs. Finally, "general maturity concerns" refers to worries that the language or std will keep changing, as is assumed they have not been perfected yet. Those are the top 3 concerns and to me, both seem to relate directly to the language or standard library.

bpicolo 10y ago
I also don't think library maturity is necessarily the only problem that makes working with libraries difficult at time. You can get burned pretty easily by someone not having e.g. Send + Sync on an essential library data structure. (Though maybe there's a way around it other than forking?) That metadata ends up being very important
- burntsushi 10y ago
  Send + Sync are automatically implemented for a type X if all of X's constituents are also Send + Sync. In practice, this means that unless you're using unsafe code, Cell/RefCell or Rc, then the Right Thing will just happen automatically. If you are using Cell/RefCell/Rc/unsafe, then you need to think carefully about your synchronization story anyway, so it's typically not something you just forget to do. For more details, see: https://doc.rust-lang.org/std/marker/trait.Sync.html https://doc.rust-lang.org/std/marker/trait.Sync.html and https://doc.rust-lang.org/std/marker/trait.Send.html https://doc.rust-lang.org/std/marker/trait.Send.html
10y ago

Dowwie 10y ago

Idiomatic Rust guides would be very helpful