Recently, there had been a call for blog posts reflecting 2017 and about which path Rust should choose in 2018.
First a few words about me. I was and still am a student, and most of my coding is for learning and because it is fun. Also, coding is a great excuse for procrastinating something more important :). Having contributed to open source codebases has helped me determine that I want to do this in a day job once I'm done with my studies.
I've heard about Rust somewhere around the 1.0 release in 2015. I don't know the details any more, but most likely it was a German tech news website. I've then read on about what Rust is and its promises like zero cost abstractions, fearless concurrency or the concept of safety really stood out. My background was C++ so I also quite liked the syntax. A bit later I decided to read the the book (first edition, back then IIRC no second one existed) and wrote my first little Rust program, with the IRC community patiently answering all my questions. It wasn't easy to get the program to compile, but once it did it was a really great feeling. With the C++ coding I did, I often ran into segfaults on after the first compile and had to debug what the cause was. With Rust, I didn't have this experience at all, and I rather have the compiler being a bit more strict than having to debug at runtime. Over the autmn of 2015 and throughout 2016 I wrote and published two crates, ogg and lewton, and in autmn of 2016 I started contributing to the Rust compiler. I've never contributed to a compiler before and all the new concepts as well as the conversations with the compiler contributors were really amazing. For the compiler, most of the stuff I did and am doing are minor things, but I've still learned a lot of great concepts and ideas.
When I've first read about the 2017 roadmap I was quite sceptical of it. Why should such a document accomplish to lead a vast distributed open source community? Also, the goals seemed weird. There were some points in the roadmap I liked, some I disliked.
Quoting the roadmap:
Rust should have a lower learning curve Rust should have a pleasant edit-compile-debug cycle
I really underestimated the value that would be put onto these first two bullet points. I've thought, okay, maybe Rust is getting nicer documentation and maybe "edit-compile-debug" cycle means faster compiles. Both seems okay!
What I didn't understand was that these two bullet points also represented what was to become the "Ergonomics and learnability initiative". This only got clear to me when talk on actual proposals started happening and blog posts connected to the ergonomics initiative got made. The issue is that I disagree with the view that the Rust language in general is very hard to learn or very unpleasant to write. Given my C++ background that probably makes sense because C++ is really hard to learn as well (I never knew all of it, only read about the pieces of the language I encountered, but knowing all of C++, especially modern and old C++, is really hard and I think that only the fewest C++ coders know almost all of the language).
So as I was accustomed to work in a language that was hard to learn, learning the concepts of Rust weren't a big issue. Most importantly, unlike the C++ concepts, many of the Rust concepts made sense. C++ is a very old language, with a long legacy. C is basically portable assembly but some of the portability choices it did backfired to developers, like e.g. not specifying integer widths for the default endorsed integer types. Rust's default endorsed integer types have well defined integer widths. This is only one of the many advantages that I think Rust has over C (or C++).
C++ is full of gotchas that make understanding code inside large codebases hard. Like the "implicit this" that it has. With it, if you encounter a member variable, you never know where that member variable came from and you wonder: was it defined in this function? Or is it a member of the class? Or maybe a superclass of this class? In Rust, Self is explicit and there is no inheritance for classes. I was quite happy about this when coming to Rust because this has always annoyed me with C++.
My biggest fear when I saw the ergonomics initiative bring out its proposals was always this "understanding code insidie large codebases" use case. When I brought up this argument, if it wasn't dismissed without addressing it at all, often the response was that this proposal made code easier to read because there is "less noise". But self can be seen as "noise" as well while being highly useful to readers, so this argument isn't always valid.
The other issue I had about the ergonomics initiative was that many proposals either improved ergonomics, or improved learnability, but only rarely improved both. I think there is a tradeoff between the two and many proposals were a bit silent about this.
Also, the ergonomics initiative didn't seem very gently executed. Some RFCs started out with quite many changes of the language which I think was quite rude to people like me who got quite shocked, and only then got reduced to something reasonable afer pushback from the community (including my humble voice) and throughout a rushed process. I think if the proposals didn't start with such wide changes, maybe we wouldn't have needed the entire rushing of the process as well as having saved the pain of the community discussing this.
In the end it was great that the impl period brought peace to the RFC discussions. So while there was a rush at the end, it was better than us still discussing these things now, without any implementation in sight whatsoever.
Also, most of the actually merged RFCs were quite conservative and were really toned down compared to the original proposals. Some changes actuall ended up really nice. Also note that with some proposals I always have been a full supporter of, like with non lexical lifetimes. My criticism is only limited to a subset of the proposals.
I really don't think we need another ergonomics initiative in 2018 or beyond, first because I don't think that generally Rust is very unergonomic to write and second because the places of Rust that still are unergonomic can be (gently) improved without prioritizing them above other, for me more important, proposals or changes.
I think one of the greatest successes of 2017 was the impl period. It was quite nice to see completely new contributors creating new PRs with substantial changes.
Rust should provide a solid, but basic IDE experience
I'm no big IDE user, I am using Kate. It provides syntax highlighting and simple autocompletion based on words that already exist in the file. Nothing really advanced. I had once been using IDEs but they limited my language choices and setting them up always was a mess, so I abandoned them and I am happier now. Also IDEs are slow. So personally I wouldn't have a great benefit in a better IDE experience for Rust. However, many people greatly value IDEs so I think having this goal was really important to gain them and to keep them. Great progress has been done in 2017. I don't want to repeat what others have said on this. Just wanting to say that it was amazing to watch!
Rust should have 1.0-level crates for essential tasks
I had been quite sceptical about this point because I thought that many crates wouldn't do it or would just get a 1.0 label without any quality improvement. I was then surprised by the API guidelines which were quite comprehensible and even though I don't agree with all of their choices, I think overall they helped improve crates.
This definitely was a success, and the success was a surprise for me. Great job!
Rust's community should provide mentoring at all levels
I think this point was another success. See the section above on the impl period.
Also, the compiler had great progress on incremental compilation, MIR borrowck, NLL, and MIRI integration, both being very important projects. I'm happy that these projects exist and want them to continue in 2018, hopefully all getting finished.
Let's now look at the future.
The first important point to remember is that there will be a new 2019 "epoch". The schedule is apparently that the epoch gets released in Q4 of this year. This seems okay for me, but it also means that there is less time than one would think. Imagine, it is only a matter of months until you can grab a copy of the "Rust 2019" compiler! Isn't that amazing?
So, what to do with the limited time that is left? Nrc's blog post has the title "2018 should be boring". I can very much agree with that. Boring means stability. It means a solid base. Boring is good.
Most importantly, we shouldn't repeat the ergonomics initiative.
In fact, some points of the initiative are still unresolved and being in an "experimental" stage, like whether to add a form of auto-clone (like C++ has), or which kind of auto-ref should be adopted. I very much favour only adopting RFC 2147 here. I don't mind experimentation but I don't see much that will change my mind on doing more auto-ref/deref than that RFC.
So any new proposal shouldn't be something overly big, but rather something doable, hopefully achievable in a matter of a few months until the 2019 epoch.
Sadly, there still seems to be no implementation of const generics. It would be really great if we could get it implemented and onto stable before the Rust 2019 release.
I would also love to see RFC 1133 merged soon, which would mean an unforking of Xargo.
Right now if you want to target some embedded platform, you need a) a linker for that platform, and b) you need to invoke rustup to install "std components" for you. These "std components" are just a bunch of precompiled crates for the target platform. Nothing really magical, but an inconvenience if you want to target something where rust doesn't ship "std components" for. And this is already more likely than you think! Think of panic=abort: Right now the std components always get compiled with panic=unwind, which is of course not what you want. So this would have advantages outside of the embedded development use case. The point a) will hopefully be resolved very soon with improving maturity of the LLD linker. One linker to rule them all!
The goal should be that embedded development is as easy as cargo build --target <embedded target> without any previous setup beyond ordinary installation of Rust.
Another area of focus could be a stable asm! macro. Right now, not even C or C++ provide such functionalities: their inline assembly is implemented as pragmas, with GCC and Clang having a different approach from MSVC (and even GCC and Clang had minor differences that Google stumbled over when they compiled Linux for their Android product with clang). The question of course is what the stability promise entails, and what may change in the future.
Steve Klabnik likes to say that Rust should become the systems programming language of the web. As much as I love Rust, and would like this to happen, right now it doesn't look like it will. Right now, Rust seems to be a bystander to existing C++ codebases being made ready for the Web. This is also nothing that Rust did wrong, its just that these codebases were written in C++ and nobody would Rewrite them in Rust just because. That is the main use case of Wasm right now. I hope that for new codebases, people will consider writing Rust however.
An exciting area where Rust+Wasm might be applied in the future is client side frameworks like the Yew framework. Also, it seems that cryptocurrencies are interested in wasm as well. So we won't just have web embeddings!
In the gaming domain, I hope that there will be Wasm support for Rust's major gaming frameworks like gfx or ggez. Some work on this is already happening! It would be really cool if you can have one codebase for your game, targetting the web, Android, IOs and the Desktop, with minimal platform specific code.
From the perspective of the compiler, there are other interesting features to explore, like source map generation support, or the addition of a raw_js! macro to provide compatibility between tools. Ultimately it depends on what other compilers are or will be doing, most importantly emscripten.
I don't think that the tight schedule of 2018 is enough to design a fully working 2.0 profiles system. I only know that Cargo would benefit from a better profiles system. Maybe in 2019 :).
Same goes for stronger static guarantees, like e.g. integrating features from wuffs into Rust that allow you to have safe check-less array accesses with patterns that would be very inconvenient or impossible with iterators. I hope they will be worked on, but 2019 is a better year for them.