Rust 2020: Growth

Distros move slower than Rust, and users of distros upgrade them slowly, too. VPS providers that I use still offer Debian 9 and Ubuntu 18.4 as the latest. That's with Rust 1.24.1, unless you hunt for backports.

Debian 10 is only a few months old at this time, so it's not too terrible yet, but consider that: it has 1.36 without async/await, and Debian 11 is going to be released in mid 2021. So async/await code that's being released now will be usable in Debian in about 2 years from now.


Yes, Debian and all distributions based on it is a huge problem for any software developer. To be honest, I don't know why would anyone use these at all. I know the pain through the range of different programming languages and tools I care about. The rustup is the only way for Debian and Co. I think the best strategy in this case is to force these distributions to remove the rust packages if they can't keep up. I remember some software project added this in its license.

1 Like

To be fair to Debian team, maintaining package repositories to ensure a stable OS that can run in multitude of environments and support extremely large set of use-cases is non-trivial effort. Not that their coffers are overloaded with cash either.

A solution here could be for Rust to publish, at the very least, an official PPA and Yum repository which could cover a significant portion of server deployments. Postgres, for example, offers one which allows very convenient way to install a custom version of Postgres (and it's plugins like Postgis) in either local or server environments.

But, then again, neither are Rust's coffers overflowing with money!


Since Rust project uses GitHub Actions now, maybe it is possible to create Debian/Ubuntu packaging action, it will also help any other project to reuse the same action.


I have been a die hard Debian user for nearly two decades now, in all kind of scenarios.

Why? Because it has proven to be a stable and robust platform. That is "stable" and "robust" in terms of always working the same and surviving upgrades over time without issue. But at the same time being prompt with security fixes.

That of course dictates that Debian does not, cannot be, constantly churning out new releases of newer software that is under rapid development. Examples are node.js, Rust, Cockroachdb, NATS. There are many others now a days.

Luckily it is often trivially easy to install those items from their tarballs or whatever and use systems like npm and Cargo. The Debian packages of the same, if there are any, go unused.

I recently started to wish Debian would not have it's own packages for such things. It causes a lot of confusion. It should just supply those packages required to support the OS itself. It's especially crazy with things like node.js where there are hundreds of node packages in Debian that should all be coming from NPM instead. Apparently this happens so as to support Node-Red.


I think another significant factor is a lack of (or immaturity thereof) a significant ecosystem for various use-cases.

For example, my company makes a device that uses the TI MSP432E4 microprocessor. The firmware is written in C and makes extensive use of existing C libraries for preemptive multithreading and an IP stack. While there is a peripherals crate for the MSP432E4, there's no HAL crate and there's no production-quality threading and IP stack crates. We cannot justify the time and expense of writing those crates, so Rust is out of the question even though it would otherwise be a perfect fit.


Rust already has image of respected language, IMHO the only reason which stops adoption is lack of people on market which is a risk for companies. It will change with the time, since it has rather open ecosystem and state of documentation in Rust is great compared to other languages, maybe more learning materials and socializing would help to accelerate adoption.

For most people rust is not the first language, and that probably explains why it inherited so many great ideas from other languages - not just inherited but thoughtfully redesigned e.g. docs, tests, workspaces, types, pattern matching, multi-thread-capable futures, async/await etc. On the other side it is quite surprising for such a strong foundational language stay flexible that it adopts to challenges fast, including syntax changes when needed (hello JS and Python), and sometimes base concepts (rip green threads), hopefully it does not change when it enters mainstream.

I also like to admit one more very powerful distinction of other languages - powerful macros, static documentation generator and hosting, build system for public crates, embedded package management provide crate producers with tools to design ergonomic APIs - in the end language will be adopted if it has easy to use libraries, hence providing crate producers with more powerful features (like GATs, const generics) will pay back with wider adoption for sure.


Rust will grow, it is the only language that can compete with C++, but it takes time for programming language to reach wide usage.

The only other language competing with C++ is Dlang but due to extensive use of GC in std libraries it will take time for them to catch up.

1 Like

Only in standard library with the idea to allow for libraries requiring their own memory management.
The other question is to which extent Dlang's standard library can be rewritten without breaking backward compatibility.
Further, ARS/RC is not that interesting for Dlang as they already have that in their GC coupled with cycle detection, they are more interested in unique ptr/ownership mgmt.
Dlang itself would never be really shipped without a GC, they do like too much, including me.

Rust is a different story.

That is what I heard, they are moving towards RC/ARC through ownership and borrowing memory model but they will keep GC for anyone who wants to use it.

Here is a blog post: Ownership and Borrowing in D | The D Blog

They are not removing GC, it will be shipped with dlang for people who want to use it.


Thanks for the link.

You could use Pickle to send and receive data between the Python interpreter and Rust code. On the Rust side you would use the serde-pickle crate.

Added bonus is a FFI interface, which is easy to implement (read from and write to a buffer).

Copying isn't always desirable, but in this case it could be a good idea in order to keep the Python GC out of Rust allocated memory.

I'm not a computer scientist, but I think doing that is an Actor model kind of communication.

One could call it "Microservice as a Component (MAAC)", if one wants to make non technical management types excited.

The diversion around OOP and traits has been moved into its own topic.


Hi, I'm leading a team of embedded developer (Cortex-M microcontrollers for IoT) in a small and young startup. Here is a chronological view of the why we haven't adopted Rust yet:
Early 2016 - Rust first caught my attention about three years ago after I saw it mentioned in the stackoverflow developer survey. I was excited about Rust mainly because of the memory safety guarantees, other niceties you cannot find in C (Cargo, unittest, etc.) and also because it was backed by Mozilla. Still, the language and ecosystem was experimental, so I didn't take it too seriously. At the time, for our startup, the main and only language chosen for embedded development was C (I personally try to avoid C++, mainly due to its complexity).
End of 2016 - I decided to give Rust a deeper look as a "Embedded C" replacement. I soon found out that embedded support was still experimental. Meanwhile, the first PoC of our embedded system is developed (in C).
End of 2017 - Rust for Embedded was stable, but I still found the tools (IDE, debugging, compiler, etc.) lacking. In startup land, first prototypes of our system are in test by one customer (all code stil C).
End of 2018 (now) - We are slowly thinking on how we can improve the next generation of our system. I would love to develop an experimental system from scratch with Rust for all the advantages the language brings, but I still fear many of the points others have mentioned. More specifically:

  • Maintaining two code bases is hard, but maintaining two code bases in two completely different languages may be even harder. With our limited resources, going with Rust feels like suicide in the short term (mainly because immaturity of the whole ecosystem: 3rd party embedded tools, documentation, compiler, etc.). If switching to Rust increases the chances of the company being dead in a year, the potential benefits Rust may bring in two years are irrelevant.
  • New features are added to the language, a few of them are cool, most of them I don't understand. That gives me this bad feeling that Rust is heading to become as complex as C++, which I decided to avoid because of its complexity.
  • Steep learning curve will be an extra burden on our limited resources. I might decide to only use a subset of Rust. Nevertheless, I need to spend time understanding most features to be able to decide which of them we want to avoid, and which ones we really want to use.

In conclusion, for the moment we will continue our embedded development in C. I might start introducing Rust on tiny non-critical projects in 2020. Maybe on 2021 the ecosystem looks solid, our start-up is more financially robust, and we might be on a better position to take the short-term risk of switching to Rust.


As an experienced Rust user, I can tell you it doesn't get any better once you do understand said features. During the last year (or so), several features have been rushed to stabilization, despite widespread controversy (at best) or almost unequivocal opposition (at worst) on the part of the users of the language. The semantics of these doesn't particularly puzzle me, but they do tend to go increasingly against the principles of simplicity, understandability, orthogonality, learnability, and elegance, which I find worrisome.

At this point I'm not sure what could convince the governing forces of the language (lang/core/etc. teams), if a repeated, emphasized, explicit dissent of the wider community didn't.


I too am worried for much the same reasons.

There is a reason C rules the roost in the embedded world. There is a reason operating systems like Unix, Linux, Windows are written in C. The ultimate and still today the only systems programming language. Despite its short comings.

My hat is off to the C standards committee guys for not corrupting C with all kind of new features over the decades. C is simple. It does what it does and that is that. They leave the ever growing and insane complexity of new language features to C++.

So what about Rust?

Rust touts itself a "systems programming language". To my mind this is only true if:

a) It does not require a run time environment.

b) It is actually useful without a standard library.

c) It just generates executable code. That I can run how I like. Like C.

On the other hand... I love the idea of a type safe, memory safe language that can be used as easily as Python or Javascript to do all the things we do in Python or Javascript.

Looks like a difficult tight rope to walk. Who knows what will happen.

1 Like

I don't think that criticism is justified, though. These new features don't fundamentally (or at all) improve type and memory safety. Rust was already type and memory safe by design from, say, version 1.0.

Said features are usually touted for "improving ergonomics", for some (often arbitrary and/or imaginary) metric of "ergonomics". They don't prevent more uses-after-free than the ownership system, they don't prevent more race conditions that the Send and Sync auto-traits. They usually consist of either syntactic sugar for a slightly more complex way of doing something, or make Rust look more like <!-- insert favorite language here -->. Neither of these is something that needs to exist in order for Rust to fulfil its promise.


I did not really want to be critical of Rust there. It is after all the only new language I have learned since 1979 that has a genuinely new and useful feature, memory safety, for a compile to native instructions language. That is the reason I am here at all.

I can't comment on the "ergonomics" thing much. To some that means making it look like Haskell. To others it means making it look like Java or C#.

Me, I want a systems programming language.

I am working with embedded firmware, and would love to use Rust. However i have mentioned it socially a few times and the main feedback i get is that we need:

  • Stable, standardized and documented ABI (so it is possible to link compiled closed source libaries and avoid requiring explicit compiler versions).
  • Multiple independent implementations, so the language as a clear specification that is independent of the compiler implementation.
  • Possibility to get a safety certified compiler (i.e.

Basically it is hard to beat 40+ years of stabilization from C. However i guess we are a bit conservative, just recently moving from C89 to C99.

When it comes to language features, i am pleasantly suprised what is possible, even though some things are a bit hard to figure out how to do:

  • Handling memory without a heap/allocator. Especially as there are plans to rewrite the syntax supporting static mutable variables .
  • Reasoning about thread safety with interrupts that may preempt eachother at any time.

I was attracted to Rust by his promise of speed and rubustness.
I liked the capabilities of external Command Calls with Result Capture.

But the most off-putting issue is that it is extremely hard to learn.

What makes so extremely hard to learn.

  • Rust knows 5 different types of Strings and each Function requires a different Type of String, but to figure out how to get from one String Type to the required one is extremely hard by its scarce documentation.

     pub fn parse_u8(text: &[u8]) -> String {
      for uc in text.chunks(1) {
          if (uc[0] >= 32 as u8
              && uc[0] < 127 as u8) {

In this example text is a Reference to a Vector of Bytes but I can't compare them to Numbers. First I need to figure out that I need to use as u8 to cast them into Bytes. But there isn't any documentation about it.

  • Rust does not allow NULL Pointer. But there isn't any documentation on how to solve the most common Programming Tasks that in other Language are solved with NULL Pointers.
  • Rust has many very language specific features that are completely new to Programmers coming from other languages. For introducing completely new Concepts of Programming (Result, Option) their documentation and mostly their application in day to day work is not clear and needs to get used to it. Also it complicates the code much more than in other languages which results in code much harder to understand and to maintain.

we can’t combine these two conditions into if let Ok(age) = age && age > 30 .

I like to add that the interesting thing about this example is that age != age because age outside the Block is a Result while age inside the Block is the Content of Result. Because after the Block you need to treat age still as a Result which can contain an Error.

  • Rust by Example Documentation: Most examples are too complicated for new Programmers to understand and thus to apply to Real World use cases. They rather want to SHOW OFF the capabilities of the Author to concadenate Function Calls. For being such complicated Examples their explanation is just too bad.

Rather on new Language Features that are not used by new Programmers focus on better Documentation
Many languages try to help the Migration from other Languages by publishing Sections aimed to help for this purpose "Pitfalls for Programmers coming from other Languages".