Rust 2020: Growth

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.

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:

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".


Most of this tasks are solvable with Options (the only exception I can think of for now is FFI), and its connection with nulls is described in The Book. I'm not sure what could be much better here.

Doesn't this worth an issue with explicitly stated unclear cases?

Taking some examples from the Forum

fn split_text<T: FromStr>(s: &str) -> impl Iterator<Item = Result<T, T::Err>> + '_ {
        .take_while(|line| !line.trim().is_empty())
        .map(|x| x.trim().parse())

That is exactly the kind of Code that People "loved" soo much about Perl.

Getting help like this raises even more questions that it solves.
And not knowing exactly what each Function Call does makes any adaption to the real use cases even harder than solving it.

But work is being done that does improve things that are more than sugar. MaybeUninit was a big one. const fn is a work in progress still but it fills a very useful space. NLL were a consequence of improving Rust's internals. Work continues on const generics but I'm hoping for a 2020 release (mind you, last year I was hoping for a 2019 release).

I'm not going to claim every new feature is like the above but not everything is async/await.

1 Like

I think @H2CO3 is referring to features like match ergonomics or impl Trait in argument position, which were subjected to some controversy that he feels was insufficiently acknowledged by the lang team.


Ah ok, I got confused between arguments it seems.

I have come to believe there is some pre-processing going on in front end of my visual cortex that filters out random noise.

Confronted with code like that said pre-processing can't recognize it as any kind of communication between intelligent beings and discards it as potentially distracting line noise.

1 Like

short resume: help like this does Rust hinder from being widely accepted by Programmers.

As an honest Answer to the Initial Question: