Rust 2020

When Rust put out a call for blogs for 2020 I knew that I wanted to answer. I love pretty much everything about Rust, and I want to be able to use Rust as my tool of choice when building anything. However, right now there is some marked pain when working on certain kinds of projects in Rust.

With that said, I think the theme of a Rust 2021 edition, and what Rust should focus on in 2020, should be Capability.

Something i'd love to see in Rust is the filling-in of a load of missing pieces in the networking API. Ideally in std, or else in some blessed crate.

Every year I think of writing a “Rust 20xx” post, and I never do, but this year I've decided to power through the procrastination, I'm also on a 5 hour flight with no Wi-Fi, so this will at least provide me with some form of entertainment!

Since I'm blessed enough to work full-time using Rust I end up having two separate sets of goals for Rust, one from the point of view of Standard Cognition (Sc) as a company that is committed to Rust, and another as someone who likes to work on projects in Rust in his free time. I'll separate both, and try to not jumble my wishes for Standard and my personal ones.

As a (late) part of the #rust2020 request, I wanted to talk about one of the paper-cuts that has become decently problematic for new and experienced users of Embedded Rust:

The size costs of formatting in Rust today are unreasonably expensive for users of Rust on bare metal embedded systems.

In January I wrote a post for the Rust 2019 call for blogs. The 2020 call is aiming for an RFC and roadmap earlier this time, so here is my 2020 post =]

Technically speaking, it’s past the deadline for #rust2020 posts, but
I’m running late this year, and I’m going to post something anyway.
In this post, I am focusing on what I see as the “largest scale” issues, and not on technical initiatives. If I have time, I will try to post a follow-up talking about some of the key technical initiatives that I think we should focus on as well.

My 2020 post will be very short, as most of my thinking of 2019 still applies.

Rust is known for its guarantees: stability, platform support, type safety and the RFC process. For a long time, those - pretty high - guarantees were also the primary source of high quality. But guarantees have become the baseline. Quality is what people actually find interesting. We already have examples of that: the Rust project ships 7 books and more non-book material, which is amazing for a programming language of our age.

I firmly believe that we should start thinking in terms of quality more.

A while back the Rust team did their annual call for blog posts asking for perspective on what the community thinks the next year in Rust should look like. Here are my thoughts (albeit a bit late).

I would like to propose that 2020 be a year where some significant focus is placed on the Rust Development Experience. I define Development experience as tooling and ergonomics that improve the quality of life of the developer while increasing productivity. In this post, I'd like to briefly explore the current state of the development experience using Rust.

Coming from a Java background, the IDE; Intellij, Eclipse, for example, form a core part of the development experience and emphasize user productivity. Fast tooling like smart auto-complete and IntelliSense aids API discoverability and helps lower the barrier to entry for new potential users of the language.
Some of this tooling is an expectation that some library and API designers assume when publishing libraries and tools.

My hypothesis is: Rust is already good enough, and ready to grow beyond status of a new/experimental language.

If you only look at Rust through its issue tracker, there are obviously sooo many things that are still missing, need to be fixed or improved. There are a few major features I'd still like to see added.
But if you look back at what has been shipped: it's a pretty good language! It already has way more features than C. It many areas it's already much more polished and mature than other languages.

So if Rust-the-language is ready to be used, let's have a closer look what is stopping people from actually using it, and fix the blockers.

Rust is an incredible language. It provides a unique combination of performance, safety and ergonomics not seen elsewhere.

It is for those reasons that within the aerospace company that I work, we have had serious discussions about using Rust in production. For aerospace and other industries where memory safety, low-level control and maintainability are necessary, Rust has a lot to offer.

Unfortunately, Rust is a ways away from use in such systems. Without a formal reference, it is difficult to use Rust in many such systems.

My thoughts for Rust 2020 are perhaps a little less aimed at new features I want to see than some other roadmaps, but more towards continuing the quality of life improvements, and expanding the ecosystem. My thoughts can be grouped into: Simplicity, A Greater Ecosystem, Compile Time, and Misc.

One month ago the Rust team put out a call for blogs 2020. I quite like these posts because it provides an occasion to provide perspective on all of Rust, by everyone. In this post I'll look back at Rust's development over 2019, and cover topics that seem important for Rust 2020.

This post is a response to the Rust core team’s call for blogs. It will outline some of my thoughts about learning the Rust Programming Language, and how I think 2020 should be a year focused on adding to the quantity and quality of learning resources available.

Answering the Rust programming language call for blog posts as input to the 2020 roadmap

Caveat: I am new to Rust. There’s probably stuff I don’t even know about that is more important than anything here. This is just me doing my part to give back to the awesome Rust community.

In this article I’ll write a little about the way I currently think about testing, and then about implementing these ideas in Rust. TLDR: Not everything works as smoothly as when working with higher level languages, maybe unsurprisingly.

This article is a response to the call for blog posts about Rust in 2020 and beyond. We’ll overview how Rust development in 2019 has impacted us as a small company using a lot of advanced Rust features for our WebAssembly runtime and tools, what we’re thankful for in Rust this year, the problems we face, and what we would like to see in the future.

Since I started learning Rust 2 years ago, my usage of this programming language has grown quite a bit. For example, this year I had the opportunity to contribute to an open-source Rust project in the context of my job: Tock, an operating system for embedded systems.

In this post I want to react to the call for blog posts on Rust for 2020. I’ll focus on 4 topics where Rust could improve in the year(s) to come: stable const generics, Rust infrastructure: reducing bandwidth, scoping unsafe code?, and towards support for constant-time code?

This is my contribution to Rust 2020, where community members put forward ideas on what they thing Rust should aim to achieve in 2020.

In my view, Rust has had an amazing adoption by developers, and is great if you are in a position to deploy it in your own infrastructure, but we have yet to really see Rust make it to broad low-level components (IE in a linux distro or other infrastructure).

At Parity we have been on board the Rust train from very early on. Aside from a few specific exceptions, our entire codebase is in Rust - including the Parity Ethereum client, the Substrate blockchain development kit, and the Polkadot network based on Substrate. We are probably one of the biggest Rust users out there and most certainly have one of the largest Rust code bases, which gives us a unique perspective in the ecosystem.

With a codebase as big as ours, we see some unique challenges ahead that we’d like to bring attention to: some bugs and language feature requests, some ergonomics and security around the compiler, and governance overall.

With that potted history given, I hope that you can appreciate where I'm coming from when I say that the one word which keeps coming up when I think about what the Rust community needs to look toward next, the "buzzword" for Rust 2020 that I'd propose, is "Inclusivity". Interestingly I don't mean in terms of being inclusive and welcoming to LGBT people, or women, or any number of other "minority" or "marginal" groups which online communities often find themselves needing to work to include; because Rust already is exceedingly welcoming to such groups -- I've never had so much as a misplaced blink when I say "my husband" in a Rust setting, and that has been so nice. What I mean is that in order to be more widely used, the Rust community needs to look toward ensuring that it can be included into other things.

Rust is a great language and has many features that make writing robust code easier. Enums on steroids, exhaustive pattern matching, constraining generics with traits, serde... I think I wish to be able to use those tools at my job pretty much weekly. Another major feature we're all familiar with is the unsafe-keyword, which lets you circumvent some of the safety nets of Safe Rust.

This article does not contain any new ideas for #Rust2020, but I still wanted to voice my opinion and support some ideas from other posts. Let’s keep it brief then. 🔑 Key takeaways: Implement GATs, Stabilize (parts of) const generics and specialization, Push more features over the finish line.

GUI is a big, big hole in the Rust ecosystem. There are a bunch of interesting one-person projects being developed and I am hopeful that something mature will evolve out of it.

GUI is a also a very hard problem to solve. However, let us not forget that Rust was initially developed to build (and is currently being used to build) a browser.

What I'd love to see is the Servo/WebRender team make some building blocks of GUI accessible and easy to use. A browser is a big GUI engine, so it should be possible to use a lot of it as building blocks.

The C2Rust project is all about translating C code into an equivalent, drop-in ABI-compatible Rust implementation. (Read our C2Rust introductory blog post here.) Along the way we’ve uncovered some dark corners of C as it’s written in practice, and found places where Rust can’t quite replicate the same code with the same ABI. This is the story of those dark corners and the areas we think Rust needs to improve to be fully FFI compatible with C.

The Rust alternative to inheritance is composition and traits. Although I like this, it still needs some improvement imho.

I’ve used Rust a couple times at work for small tools, and written a couple of experiments in Rust. So before saying what I want out of Rust, I’d just like to say thanks to the wonderful community. I liked the Rust 2019 progress, and I can put most of my wants for 2020 under two main labels: Embrace and Extend.

In my Rust 2020 blog I tried to shy away from specific feature requests, instead zooming out to look at the Rust ecosystem as a whole. As a community, we've achieved great things but we should take care not to crumble under the weight of a scaling language and ecosystem. We all need to come together to ensure that Rust can sustainably scale - be it in large organisations, communities, or codebases.

We need to work on error handling.

Rust could make the lives of (data-) scientists a lot easier, but as with most new programming languages it's a chicken and egg problem: When the applications and libraries are missing people will not use it and when there are no people with domain knowledge there won't be any applications / libraries. We do have some good projects like ndarray, RustSim, uom, etc. but we definitely need more (some stuff is also mentioned here Not-Yet-Awesome Rust). I'll try to work on more Rust stuff in 2020 and hope that more people will recognize Rust as a good candidate for scientific / numeric / high performance computing.

Another year already and I’m still knocking myself out using Rust. It is also the year where I can use Rust in a professional environment with people interested in the technology. Let’s review my last year post and try to come up with what I think Rust should focused on for the next year.

I am writing this to announce a lame, but hopefully fruitful confession through this post. I had originally intended to make this a Twitter thread, but eventually the Rust 2020 call for posts emerged, and I saw it as an opportunity to expand this.

In general I tend to be conservative about adding things to the language and want to push as much „downstream“ ‒ it’s better to add something to the standard library (or core, if applicable) than directly into the language ‒ a new function is better than new keyword or operator. A new crate is better than a lot of new stuff in the standard library. My view here reflects that.

I like Rust and I'm looking forward to more improvements. My suggestions: RLS should be better and faster, Const genrics, and Accept more correct programs.

Its that time of year again and its been exciting watching the language grow over this past year! Looking back through the Rust releases for the entire year, starting with 1.32.0 there’s been some fantastic progress, which is pretty easy to forget! So why not start with a bit of a recap of some of the big things from each release.

This is my answer to call for blogs 2020 and somewhat an update to my post from last year. You don't need to read the old post though, since this post is written in way that it incorporates that content as well.

For every topic, I will present my personal favorite parts, split into Completed (compared to the post from last year or was not on the list but is nice anyway), Open (existed last year and is still relevant), and New (got relevant or new idea).

The Rust language itself went 1.0 in 2015. And yet, almost 5 years later, at least in my anecdotal assessment talking to and reading things written by current or potential users, there is still a sense that the language is still in some way unfinished and a bit rough around the edges. I sympathize with these concerns.

I’ve been following Rust for long enough that I remember the early days (pre 1.0) where the language would keep changing from under me and I’d have to regularly rewrite parts of my project using the latest syntax. Fun times!

Of course, things have changed a lot since then. The language has stabilized and we have Rust Editions to rely on for major releases. However, even though changes to the language are backwards compatible, there is still quite a lot of churn due to new features being added.

In response to Rust's call for blogs about Rust development in 2020, here's a few of my own thoughts: Improve Error ergonomics, Stabilize existing approved features, Stabilize more ecosystem libraries.

Blog posts that praise Rust are many but funding is generally in short supply. If even a small percentage of the money Rust saves companies was put back into the ecosystem it would help secure the future of the platform tremendously.

I’m a Rust user rather than a Rust developer. I have been writing Rust code since just before the 1.0 release, and have followed the development of the language since then. I believe the future of systems programming is likely to be in Rust. I am certainly invested in the Rust language. Last month I resigned from my job writing embedded C, so I could start my own company, producing IP Networking software in Rust.

When I read the Nick Cameron's 2020 blog post, I thought about something that might be interesting about editions. One of the Nick points was that a 2021 edition would be useful as a rallying point to highlight progress on “async”. I agree that a rallying point is desirable, but I believe the edition system is a terrible way to do that...

It’s again the time of year when the Rust Core Team calls for blog posts for input into the next year’s roadmap. This is my contribution. It’s mostly a re-run of my Rust 2018 and Rust 2019 posts. Apart from the LLVM bound check optimization item, the theme here continues to be: Please mark features that have worked since 2015 as done.

I'm using Rust actively and it's mostly great. That said, there are some pain points: We are not compile just yet, We aren't cache yet, and We are mostly doc already, but not completely.

It is that time of year again. The Rust Team is soliciting ideas about rusts roadmap for the next years, so here goes mine. Thinking about the tagline I would give the coming editions, it is this: Rust 2015: Stability, Rust 2018: Productivity, Rust 2021: Confidence. I will explain what this means for me, but lets digress a bit first

I'll start by arguing in favour of an edition in 2021. Then I will indulge in some rumination on the nature and necessity of roadmaps. Finally I'll make some probably obvious points in a long-winded way. Tl;dr, money is a thing we need to think about, async programming and WASM are important, and the compiler should be faster. For good measure, I will re-open a can of worms concerning the standard library.

Some weeks ago the rust-lang team made a blog post asking for opinions on what the priorities for the next year should be. It really amazes me how the team hears everybody and how friendly the community is.

I have been learning rust for more than a year already, but this year was the first where I tried to write something real and production ready with it. I've gotta say I had a lot of ups and downs with it, but I'm still amazed by the language and its ecosystem.

In which I respond to the recent call for blogs put out by the Rust core team and write down my wishes for Rust in 2020. Yup, GATs and const generics are there, but also slice patterns and a request for better documentation around async development.

I must have missed an e-mail in my inbox, because recently I started seeing people publish Rust 2020 blogposts so I thought, why not. I haven't been incredibly involved in the development of Rust in the last few months, (navigating the delicate balance of being self employed, working on free software and not burning out) but I feel like that might change again. And also, I still have feelings about software.

This post was also largely inspired by my friend XAMPPRocky's post, as well as attending NixCon a few weeks ago, and generally interacting with the NixOS RFC process.

Here we come with the "Request for Comment" about Rust for the next 2020 year. I'm sure 2020 will be a great year, also because it's easy and fast to write :) My wishlist will be short and to the point. Looking back to what I wished for 2019 I'd like first to see what has changed, from my point of view.

Thing that is cool: writing the same codebase and having it run on desktop, mobile, and web thing that is lame: JavaScript is the only language where people really do that right now, outside of big commercial game engines things that need to happen for Rust to get there…

This year I decided to jot down some thoughts for the Rust 2020 call for blog posts. I think the general theme here will be integration or "playing well", on different levels. A lot of these here are not language changes, and most of them already exist in some form. Probably none of them are new ideas.

This is my personal wishlist of things I'd like to see in 2020 relating to Rust. It only contains technical items, not because I disagree with the people who say we should prioritize some non-technical things, but because I feel like I don't have much of value to add to that topic.

I've been working on the Rust compiler for years. It got stabilized, then matured through the years. From my point of view, it now has most of the features I wanted. So what would I want for Rust 2020 and what's coming after? To sum it up: feedbacks.

The call for blogs was just issues a few days ago - and here I am writing about my biggest pains this year… because that’s what the call for blogs basically is for me… I write down my pains with Rust and hope things get better slowly next year.

Don’t misunderstand what I want to say here though: Rust is awesome, has an awesome community, awesome tooling, awesome everything… well not completely (because otherwise I wouldn’t have to write this article, right?

I’m fairly new to Rust, and thus my perspective is that of someone who is not quite sophisticated with the language. I think Rust is hard to learn but should be manageable for your average software developer given enough persistence. Once you are over that barrier, you start thinking of building something in Rust. Probably, for the web, or a desktop application, or a mobile application; because that’s largely what many developers are building today.

For the 2019 roadmap Jonathan Turner wrote a blog post called the The Fallow Year that posited that we should let the new designs "field" rest (go fallow) while we focus on other areas. To extend that metaphor, I would say Rust has fallen into monocropping in 2019 by focusing too much on our technical debt, when we needed to be addressing our social debt.

User growth means accepting people that haven’t been exposed to Rust’s norms yet. Let’s not fracture because of an argument over top-posting vs bottom-quoting or something equally trivial. We need to make sure that Rust is prepared to welcome people who are just learning about Rust today. We don’t want anyone to feel like they’re late to the party.

This is just a brain dump. Doing all of this is not going to happen, but all of it is stuff I know of that impacts Rust's integration with the rest of the world and eventually becoming Too Big To Fail like C++ is.

In response to the call for blogs about the vision for Rust for 2020, I’m going to write about GUI. I believe the time is right for a native GUI toolkit written in Rust, and that such a thing would fill a very important niche. There is a demand for performance (which, to me, includes startup time, RAM footprint, and binary size), and Rust is in the best position to deliver on that.

We have all been called upon by @rustlang to share our thoughts on what we want from Rust in 2020. My wants are centered around the developer/debug experience more than the language itself. I find the language to be expressive and attractive for many types of development, and I find the community to be very pleasant.

This blog article is a small reply to the public call for blog posts 2020 in the Rust community. I will express what I would like Rust to go to, keeping in mind that it’s solely my ideas and opinions others’ might differ. The points expressed here are written by decreasing priority, starting with the feature I would like the most to see implemented as soon as possible.

Every year there’s a call for blogs reflecting on goals for Rust for the upcoming year. For me, the theme is “Community First”.

This year, I am quite divided due to a bunch of competing desires: I still want all of the things that I wanted last year. In particular, it would be great if OS developement could finally be done on stable rust. Things like inline asm are blocking this. I think there is still a great deal of technical debt left over. I'll talk more about this later. It's not clear what the right balance of new features and working on technical debt is.

Comments on the call for blog posts in 2020 on Reddit, some of which include 2020 wishes.

In 2019 the big focus was async/await, or at least as an outsider that is how it has appeared. The end result looks like it will deliver what we’ve all been waiting for - efficient async code that works well with Rust’s borrow checker. As 2019 is coming to a close and async/await is stabilizing, there is the obvious question - what next?

The Rust team asked for 2020 roadmap blog posts, so here goes: Let’s do more of what we’ve been doing so far.

For the 2021 edition of Rust, I'd like to see private enum variants.

The 2019 goals for the Rust project were to finish some old language and library features that have had a lot of design but have not been pushed through the finish line.

2019 was another huge year for rust, but instead of implementing the shiny new thing, it's been a focus on refining existing ideas. Having being using rust professionally for over 3 years, I feel I will very soon be regailing new rust developers of the times before NLL & async, where we had to play lexicon-fu to get things like caches to work in a reasonable fashion, or using super dooper combinator chains and wrestling with futures types (Either::A/B anyone?). So I'd like to make clear my acknowledgement that I am happy with the direction that the rust language is heading in, and these requests are really nice to haves.

I'm a no name who's just grateful to play around with Rust. The most exciting aspects of Rust is seeing a expressive language go where other languages can barely tread (wasm,linux kernels, microcontrollers). I hope Rust continues to be the bleeding edge tech in web assembly land. I would dream for a world where Rust team works closely with browsers and what new wasm features will drop, and Rust is first to get it. no_std, async, and alloc have added a lot of fascinating new capabilities to the wasm ecosystem, i'd love to see some aspects get stabilized in this realm.

With async close the completion everything looks to fall perfectly in place for maintaining the developer momentum that Rust has picked up. The language has surely shown to be approachable, flexible for new concepts and continues to be loved. So are we done? Of course not. I would like to see next years theme be Integration.

We are accepting ideas about almost anything having to do with Rust: language features, tooling needs, community programs, ecosystem needs... if it's related to Rust, we want to hear about it.

One big question for this year: will there be a Rust 2021 edition? If so, 2020 would be the year to do a lot of associated work and plan the details. What would the edition's theme be?

For a while I didn’t really feel a need to write a blog post for 2020. As far as I can tell we the Rust Community are doing a great job, and I just want us to keep doing what we’ve been doing. My biggest worry is that the people who contribute the most are dangerously close to burning out and I made a tweet much to that effect.

But I was talking with someone recently about what makes Rust great, the language and the community, and that ultimately boiled down to how inclusive and accessible we are, and it made me think saying more than just “keep doing what we’re doing and take care of yourselves” is in order.