Rust 2019

Howdy y'all. This is a super late 2019 goal post but I drank too much coffee this morning and wanted to get some thoughts out. I'd love to see 2019 be a great year for progressing the environment for developing audio applications in Rust. I'm not saying that there aren't already some good libraries out there, but in comparison with the defacto C++ offerings, we have a long way to go. Basically, I'd love to see an alternative to JUCE in Rust, and that is very ambitious because JUCE is an amazing library!

Rust has been my favorite programming language lately. These are my thoughts and opinions on the future of the project, in response to the #Rust2019 call for blog posts. I write about what I love about Rust and what I want to see from it.

The goals and 2019 roadmap of Rust Secure Code Working Group

2018 marked my second year as a full-time Rust developer, and I’m happy to say it’s the first year I shipped production Rust applications. Thus far these applications have been unproblematic, quietly and efficiently doing their job, and just as boring and predictable as I’d hope they’d be. I would like to hope my experience is repeatable, and that 2019 is the year that Rust can transcend the notion of being a bleeding-edge science experiment and instead settle down into being a “boring in a good way” practical language with a growing community developing and deploying production-quality software.

The Rust Wasm team has made tremendous progress in building robust developer tooling for Rust targeting WebAssembly on the Web in 2018. However, Non-Web Embeddings are also supported by WebAssembly but have not received much attention yet for Rust Wasm tooling. Our wish for Rust Wasm 2019 is to improve the tooling for Non-Web Wasm Embeddings which we believe also has enormous potential.

Two days ago I wrote about what I plan to work on this year. This is my post about what I'd like to see happen with WebAssembly and Rust in 2019.

This year another call for community blog posts on the future directions for Rust is up. This post re-iterates some of the points I mentioned last year (including simply copying some parts of the text), while re-stating the issues in the context of Rust 2019. A summary is that I think that the two most important themes is community management and support for awesome libraries. The why, how, and what is discussed below.

2018 was a very busy year for the Rust project. A new edition was released, progress on stabilising Rust’s asynchronous I/O story was made, a new website was launched, and so much more! In 2019 I’d like to see the language and wider crates community become more sustainable, address some common gothca’s that newcomers experience, and promote more platforms/architectures to tier 1 status.

I want to tackle one specific topic in contrast to other posts that are mostly from a different perspective, and I want to paint the "Big Picture" and overall direction. This post is about the narrow topic of GUI and I want to make a case to convince, at least a fraction of the community that is interested in this field, that it might be a good idea to invest in this direction.

Some of my first real, non-toy projects in Rust, way back in 2015, were numeric. I was taking a graduate-level Reinforcement Learning and MDP class at the time, and shortly after transitioned to using it in my research in AI. Rust has a lot going for it in terms of package management, speed, and typing.

Unfortunately, it falls apart in several fundamental areas when it comes to mathematical and scientific uses. Some of these are ecosystem problems (i.e. the work just isn't there) and some of it are more core problems (e.g. type-level numerics, which will be solved Soon™, hopefully).

I think in 2019, we should make a coordinated effort to improving the foundations for writing unsafe code. Of course my particular Rust bubble is mostly about unsafe code, as you will know if you have read some of my previous posts – but safety is a core value proposition of Rust, and the entire ecosystem rests on a foundation of crates that make heavy use of unsafe code, so I believe that caring about unsafe code is an important piece to Rust’s overall success.

We rely on Rust. So do our customers, sometimes without even knowing it. We build software that is installed on devices that go out into the world, sometimes never to be seen again in years or even decades. But 15 years from now, we may get a request to make a change to that software.

Historically we have been very successful doing just that, first in C and later in Java. Slowly but steadily, we are coming to rely on Rust to be able to create maintainable mission-critical software for our customers.

Therefore our proposal for the 2021 roadmap: Reliability.

This blog post reflects on our journey up to the 2018 edition and outlines our view on Rust's progression in the coming years.

Rust in 2019 and beyond: In response to the call for blog posts on the direction Rust should take in 2019 and beyond I’ve come up with a few ideas.

The problem is now that if we are measuring safety of Rust according to safe vs unsafe, the most obvious metric to optimize for is amount of unsafe lines in the code.

And this is why I think that security should be part of Rust’s stable ecosystem development. And 2019 should be the year for improving the processes around it.

As with any wish list, it started short and then grew a bit. There are three sections Community, Technical and Ethics and I hope it is not too lengthy.

The Rust maintainers recently asked the community what they would like to see happening in Rust, in 2019. Many people have stated that Rust could use a fallow year. I generally agree, but there are a few changes to the language I consider important/useful enough to implement despite the proposed moratorium on features.

During the RustFest 2018 in Rome, Aaron Turon said something that stuck with me, which was that Rust is actually about empowering developers. Personally I think this is a very profound thought, that the goal of a programming language is to help others to do and achieve things they never thought possible.

JavaScript empowers developers by being accessible - everyone can start and succeed quickly. It’s great. Rust on the other hand empowers developers by giving them the tools to go deep.

Let’s unpack that.

To me, 2018 felt like a big turning point for Rust, and it wasn’t just the edition. Suddenly, it has become “normal” for me to meet people using Rust at their jobs. Rust conferences are growing and starting to have large number of sponsors. Heck, I even met some professional Rust developers amongst the parents at a kid’s birthday party recently. Something has shifted, and I like it.

As of Rust 1.30, the Rust language now has support for a very expressive feature called procedural macros 3. Procedural macros are great because they enable Rust to do more, without baking a lot of potentially domain-specific information into the language. For example, automatic serialization of data types 5 and expressive, type-safe abstractions for web servers 6 can both be implemented using procedural macros.

However, while expressive, procedural macros can’t do everything.

The Rust community requested feedback last year for where the language should go in 2018, and now they are running it again for 2019. Last year I was too new in Rust to organize a blog post, but after an year using it I feel more comfortable writing this!

In this post I will be focusing more in two areas: array computing (what most people consider 'scientific programming' to be) and "data structures".

In 2014, world-renowned C++ expert Scott Meyers was invited to DConf, Facebook's conference on the D programming language. D is a modern, multi-paradigm systems language with a good amount of inspiration from C++, so the choice was only fitting.

I'm not a contributor outside a few issues here and there, but I have some thoughts about how Rust could be improved in 2019. There's been a lot of talk of the Fallow Year and limiting new features, and I think these are great ideas. With that in mind, a goal that follows along those lines is to "Beat C++." Rust doesn't have to beat C++ by performing better in benchmarks. Rather, Rust can beat C++ by making it easier to write optimized code, benchmark it, and profile it.

When starting collecting ideas about this years Rust 2019 post, I had far to many to fit into one document. For that reasons, I’ll start writing multiple small pieces. I might come back to them at a later point this year. Most of my wishes are around the project structure, but I also have some technical ones. Most of them deal with the current growth and maturity of the project. All of these are living documents and even just drafts, so they might change at any time and might be released in draft form.

Thinking about Rust’s evolution like a video game (heh), we have just reached level 2018. Our programming language is in a good state but there are a lot of progress bars for features where we need to get a few more experience points to unlock a new ability.

This article is a repsponse to the call for 2019 wishlist blog posts for the Rust programming language.

It's starting to become a tradition to see a bunch of posts around the new year on what the community wants to see from Rust. For the second year in a row, the Rust core team asked for feedback for the 2019 roadmap and this is what I'd like: "rustfix all the things" and a better infrastructure.

These are some rough notes on things in the Rust project that are important to me, that I’d like to work on in 2019. I haven’t got a grand vision this time around (I tried that last year, but ran out of bandwidth to properly drive it).

Many people have already posted their thoughts on the future of Rust. There are some excellent ideas in there that are probably more important than what I have to say. On the other hand my blog post covers my personal experiences I’ve had in the few years I’ve been writing Rust.

Like last year, the Rust community team asked community members to write blog posts "proposing goals and directions for 2019"; this is mine. Like withoutboats' post and Niko Matsakis' take, this post will focus on organizational issues. As such, the "ownership" from the title refers to a leadership principle, not the technical type system concept we all know and love.

This post is gonna be as much personal as it is both technical and people oriented. Buckle up, we’re gonna cover a lot of things, and a lot of it is not fun. This is definitely one of those, “We really need to look at ourselves in the mirror” hard truths posts. As I type this though, I’ve reflecting on the past few years with the Rust community I’m just in awe of the amount of work, dedication, and passion that’s gone into it. I started Rust when I was still starting my career and finishing up my CS degree and now we have a brand spanking new edition! So much has changed that it’s honestly mind boggling thinking about it. Even at work I gave a history of Rust presentation and it was wild being able to go “back in the day” for something that was just a regular day a few years ago.

Now I find myself thinking about the problems we face as we become an even bigger community. We have a lot of problems. They’re good problems to have, but problems that must be solved eventually. I’m gonna go through all of them, what I see as major pain points/issues we’ve solved up to now, the present problems, and ones on the horizon. I’ll cover what I think we should focus on in the upcoming year and where we can go towards for Rust’s 2nd Edition. Let’s get started!

Since there are plenty of blogposts about what people would like to have or will implement in rust in 2019 here is mine.

I spent the last few weeks of my spare time making a C-api for rav1e called crav1e, overall the experience had been a mixed bag and there is large space for improvement.

A call to action for local Rust meetups.

In my opinion, one of the biggest reasons why Rust is so productive is that it's a superb language for code reuse. Despite all these strengths, there's one problem that sticks out like a sore thumb: trust. Every additional dependency is another piece of code that could be buggy, or even malicious. And in my opinion, it's problem so serious, that is entirely blocking the untapped potential of code reuse in Rust.

A lot of people already know Rust is a great systems language. It can be put on embedded, feels better than C/C++ in many ways, and concurrency is way better than it was before. It's almost no doubt that Rust will continue to grow in these realms. The opportunity I see Rust has to lose though, is being the defacto language of the future of serious web programming. The dream I see is Rust as the language every one uses to create backend, front end, and perhaps even the distributed web ( wasm distributed apps on blockchain implementations).

This is my personal answer to the call for Rust 2019 Roadmap blog posts. To make it easier to read I've separated the post into sections by topic: Cargo & Crates.io, Rustdoc, Language & Stdlib, Compiler & Analyzer.

2018 was a success with the stated goals of releasing “editions” and working on usability/ergonomics. My first encounter with Rust was pre-1.0 (early 2015) and I immediately saw that Rust would be my future, wherein I joked to colleagues that I’d use it to “make toasters talk”. Followed by a sizeable hiatus (lack of personal time), I came back mid-year 2018. I can say for certain that the focus on usability and ergonomics was successful. Rust is much easier to use now than it was then. Rust format (rustfmt), Rust language server (RLS), text editor support, cargo tooling, compiler messages, and ecosystem crates’ quality and diversity are all amazing. The community is crazy diverse (first language learners, experienced systems people, web-dev people, programming language theory people, etc…). The chaos is well-managed with self-organizing working groups.

For the first time, I’m writing for the Rust Roadmap blog posts call. Why this year? Maybe because after being part of the community for 3-ish years, I feel I’ve reached a level of knowledge of the language that allows me to talk about it. I’m far from being an expert, but I wrote an application of my own and I am contributing to Cobalt. Enough experience to give me some material to think about.

Tame Complexity through Community Involvement Tools

This year is also a bit special; in 2018, we introduced “editions” to Rust, on a roughly three-year schedule. So now is not just a good time to think about 2019, but about 2020 and 2021 as well. Rust 2015 was about “stability”. Rust 2018 was about “productivity.” I’d like Rust 2021 to be about “maturity.” In order to get there, here’s what we need in 2019.

This is my answer to the call for blogposts about what I’d like the year 2019 to mean for Rust.

This is a blog post (as solicited) about my suggestions for the Rust project in 2019 and beyond. I should note that I am speaking only for myself, not anyone else, and not even as a very active participant in Rust anymore. Moreover these suggestions, to a large extent, apply to many projects. Rust is just one case, but one that is currently doing some conscious year-end reflection. I should also note overall that I'm quite pleased by the trajectory of the Rust project and this suggestion is being made only in the spirit of keeping it healthy and on-track, avoiding some problems I observe developing in it, as a mostly-outsider these days.

I am a relatively new in Rust, but I believe I have gathered enough experience the last few months to enjoy its strengths and discover some of its current shortcomings. Being relatively new at Rust, I am also of this generation that started immediately with Edition 2018. I switched to nightly very early on, and recently have been porting some code back to stable (1.31.x). I am overall very satisfied with Rust, but sometimes I come across something that doesn't work as I hoped. Every time that happens, I discover there is work-in-progress solving these issues, including, most of the time, a merged RFC, a nightly implementation behind feature gates or at least some blogs from core developers. Many time, the work I come across is from many years back.

I have read several #Rust2019 and I want to use this opportunity to agree with those that suggest to finish current core stuff.

I’ve written a single library in Rust, called Horned-OWL for manipulating OWL. The experience has been positive. There is already a good and complete library for manipulating OWL called the OWL API, so I needed a strong motivation for writing another. That motivation is simple: the OWL API is in Java and it is slow. Rust has fulfilled it’s promise for me; Horned-OWL is an order of magnitude faster thatn the OWL API. What have I learned from the experience though, and what could be improved?

Rust made good progress in 2018: const fn in particular was a welcome and sorely needed feature. With #[panic_handler] now stable, we can finally write no_std binary crates on stable and not worry the next release will break it. We got some other useful features, including the following: u128, NonNull, fixed-length slice patterns, LTO, #[repr(transparent)], #[repr(align(_))] In 2019, I have one major wish for Rust: Const Generics.

It’s the time year to reflect on the past and to make wishful prospects for the future.

If you’re familiar with the history of Rust you might be confused with a call to stabilization. After all, Rust 2015 (a.k.a 1.0) was all about stabilization and the team has actually done a pretty good job with achieving this goal. So what gives?

While Rust 2015 defined stabilization around language backward compatibility, it’s time for the language, the tooling, the ecosystem and the governance to stabilize. Each of these characterize stability in a different way. Let me explain a bit more what I mean.

TLDR: this post is not as eloquent as I’d like it to be, but the main takeaway
is that Rust is still a fast growing language, and has experienced expected growing pains,
both social and technological. This is okay, and we as the community need to
work through these pains, with the teams, not despite them.

This isn’t exactly a blog so this won’t be exactly a “post”, but I’d like to write down my thoughts on this notepad answering the call for a wishlist for Rust 2019. Opinions expressed are from the point of view of an enthusiast, Rust apprentice, that happened to be knee-deep involved in organizing the RustFest in Rome. It’s fun to pin today some thoughts and see in 12 months how things will have evolved!

As a response of https://blog.rust-lang.org/2018/12/06/call-for-rust-2019-roadmap-blogposts.html 3 for tooling improvement. Nice to see rust improved so much these few years on productivity but I think there is room for improvement. This would be my first post about Rust after hanging around for quite some time.

Things I would like prioritized in the 2019 roadmap: Reduced Compilation Times, Refined Tools.

I'm writing in Rust a lot less than what I'd like, in part because of the lack of time, in part because the language and developer experience are already good. What I found missing is...

I have many technical wishes for Rust, the language, in 2019. However, I’m not going to mention any in particular in this post. In fact, I can almost say that I’d prefer for there to not be a focus on achieving technical milestones in the next year.

This is a bit of a brain dump of my thoughts about Rust 2019. Mainly I work on my own code coverage tool tarpaulin, embedded rust and random little tools. So my perspective will be coloured by this.

Recently, the Rust Core Team solicited blog posts on where Rust should be headed in 2019. Here’s mine.

We all know that classic aphorism: Year comes to an end, Rust blog post press send. This is mine.

There are lots of cool technical improvements to Rust that I want the project to achieve this year, and a few in particular that I’m definitely going to be putting a lot of time into. But this blog post is going to talk about none of them. Instead, I want to talk about organizational debt, and how badly the Rust project needs to deal with it in 2019.

The Rust team encouraged people to write blog posts reflecting on Rust in 2018 and proposing goals and directions for 2019. Here’s mine. This is knowingly blatantly focused on the niche that is immediately relevant to my work. I don’t even pretend this to represent any kind of overall big picture.

2018 was a massive year for rust, and it's great to reflect back on how far we've all come. My main wish for the new year is to put on the breaks a little bit, and finish off what has been started without taking on anything majorly new.

Rust needs to focus on less glamorous features in 2019. We have added a lot of great features since 1.0, but we need to address the warts that we have had for a long time. I mostly echo sentiments from Jonathan Turner, Nathan Vegdahl, and many others in my ‘fallow-year’ sentiments. Overall, Compilation speed and generic constants are my two most wished-for features. On top of that, I would like to see more ecosystem work to make embedded applications more feasible and easy to use. Finally, Rust needs a moratorium on adding syntactic sugar for 2019.

This might be an uncommon opinion—especially among those motivated enough to write a Rust 2019 post—but I actually think Rust is pretty much at a good place now. For the kinds of things that I want to do (e.g. my path tracer), there isn't much that Rust is lacking as a language. There are some fiddly things like "placement new" that could be useful, but nothing really major. And of course, well-designed new features are always welcome, they just don't seem particularly critical to me at this point. In other words, I'm pretty much satisfied. Mission accomplished, as far as I'm concerned. I think the rest is just polish. Just the little things.

I hope this post doesn't come across as a laundry list of stuff to do. Mainly, I consider a lot of this to be technical debt, and I would like to see it paid down a bit. Most of them also happen to be pain points that I have come across in my own usage of Rust, so perhaps I'm biased! Feel free to let me know...

Rust shines when we find ways to have our cake and eat it too: memory safety without runtime garbage collection, abstraction without overhead, threading without data races. We must find new ways to continue this tradition for Rust 2019 and beyond.

A response to the call for 2019 roadmap blog posts. In case you missed it, we released our second edition of Rust this year! An edition is an opportunity to make backwards incompatible changes, but more than that it's an opportunity to bring attention to how programming in Rust has changed. With the 2018 edition out of the door, now is the time to think about the next edition: how do we want programming in Rust in 2022 to be different to programming in Rust today? Once we've worked that out, lets work backwards to what should be done in 2019.

Recently I've been using Rust for GBA development (repo link), and before that I spent most of my Rust time with Handmade Hero work (the actual repo is private to handmade hero backers, so that link is just the main website). As you might expect, this has given me a quite different view of what I want to see from Rust. Basically, I don't want more crates. I want language, and tools, and most importantly education.

Last year for Rust 2018 I didn’t write a post like this, hoping to see other people write it. But even with a hundred plus posts that didn’t happen, so this year it’s the moment to speak up. I have used many different languages in past and when I started studying Rust at version 1.0 I was quickly impressed by its very good design, I was mostly in agreement with most of its design decisions, despite every useful language has a messy implementation. Even small things were designed with care. And I loved how much Rust cares for code correctness. I prefer to avoid long debug sessions and to use more time in the design and coding phases. So I’ve kept learning and using it ever since. For 2019 and beyond I’d like Rust to keep working on finishing its many unfinished parts.

We should drive home the goals set in spirit of productivity in 2019. We should also consider composibility as the next overarching theme.

The Rust community team is soliciting blog posts to help plan the 2019 efforts. So here’s my take. I’ll start by looking back at the last year. We’ve seen great and impactful changes in the Rust landscape, such as non-lexical lifetimes, the stabilization of procedural macros and const fn, stable clippy and rustfmt, the further development of powerful IDE integration such as IntelliJ, Atom and VSCode.

Rust is an amazing project. It’s unlike anything I’ve ever seen. Not only are we seeing an ever-growing number of big name users of Rust, we also continue to see leaps in productivity and functionality. Yesterday, the Rust 2018 edition shipped. The culmination of three years of work, it shows off what the community is capable of: new features, backwards compatibility, new ergonomics without sacrificing performance, and the list goes on and on.

Which is why it might comes as a little bit of a surprise that I suggest we let the field rest for the year. More specifically, that we should let one field rest while we plant another. Rather than focusing on new designs, I suggest we turn our attention outside of RFCs to other areas of Rust.

Proposing Amethyst as our flagship project.

A wishlist of what I would like to accomplish with Rust in 2019.

Many people have asked me what I’m working on lately, and I thought I’d give a quick rundown of my status and plans for 2019. I intend to keep this post updated with the status of projects as they progress.

I think Rust could help at the task of writing performant computational software, because its expressiveness, flexibility and degree of low-level control rivals that of C++, which is the de facto dominant programming language of this community where sophisticated abstractions and high performance are both desired. All the while being vastly easier to learn, and to use correctly and efficiently at the same time.

I think there is too much unfinished and unpolished stuff in Rust. My wish for 2019 would be to ship most of this. If I had to choose a theme for Rust 2021 that would be "Reliability", to convey that what is shipped has actually been polished to the point that it does not fail.

Starting today and running until of January 15, we’d like to ask the community to write blogposts reflecting on Rust in 2018 and proposing goals and directions for Rust in 2019.