Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022 (opens in new tab)

I am somewhat pessimistic because LLVM is significantly behind GCC in debug information quality (for example, see https://robert.ocallahan.org/2018/11/comparing-quality-of-de...) and there is limit to what Rust can do about it short of fixing LLVM.

> there are tools that don't require manual memory management or being pedantic about the different types of strings. You could just use Go, Java, Haskell, Python, etc.

1. Rust doesn't force you to do manual memory management. Rust memory management is automatic by default and only if you really, really want to, you can do it manually.

2. Memory is not the only resource. The GCs in languages you listed only solve the memory management problem, but regarding the other types of resources, their ergonomics are often worse than C - you have to remember to close the resources manually and you get virtually no help from the compiler.

3. None of the listed languages address problems related to concurrency, e.g. data races. Ok, Haskell kinda avoids the problem by imposing other restrictions - by not allowing mutation / side effects ;)

4. Rust offers way better tools for building high level abstractions than Go, Python and Java. It has set a very high bar with algebraic data types, pattern matching, traits/generics and macros.

> “and the ownership of resources by the device (which Rust doesn't solve for) are correct.”

For embedded software, the underlying code basically reads and writes a bunch of registers. Unsafe memory access with side effects. The benefit of using rust here is that you can easily model these access patterns to make an api that cannot be abused. So the driver reads and writes addresses and the user code operates through the driver with all the benefits of ownership at hand to avoid race conditions and other foot-guns.

So, in this way rust does indeed “solve for” ownership of devices. You can’t have two threads (or interrupt handlers) mutating the same device without satisfying the ownership rules.

Rust does actually do the many of the same optimizations, and in unsafe rust this can and does lead to UB.

An example of this, is aliasing mutable references. Rust has been designed to assume that two mutable refs will never alias, if you attempt to do this it is instant UB. My understanding is that even creating the aliasing reference is UB, even if you don't use it.

Another example would be uninitialized values. In rust, the compiler assumes that values are always "valid" and initialized. Since you need to allocate memory before writing to it, you need some way to safely have uninit values, and this is what the MaybeUninit wrapper type is for. The wrapper allows you to safely have uninit values, and once you write to them you can tell the compiler that they are initialized, but if you tell the compiler before on accident, it is UB.

References also are guaranteed to point to initialized and valid data, and can never be null, though my understanding is that there is some uncertainty about the exact rules of this with regards to uninitialized values and the exact semantics may change in the future.

(There are also a lot more things that I don't know very much about!)

All of these things are assumed to never happen, and optimizations are performed based on that assumption.

The nice part about rust, is that it makes it impossible to represent invalid states using the type system!

For aliasing, you can only have a single live mutable reference at any time, attempting to create a second one while another is live is a compile time error!

For uninitialized values, you simply can't create uninitialized values at all in safe rust. My understanding is that the only way to create an uninitialized value is with the MaybeUninit type or by using raw pointers.

So rust still has heaps of UB, but it doesn't allow you to do it by default, so you still get some of the optimizations you'd expect.

I think there are some cases where rust is missing out on optimizations though, like with signed int overflow for example, and probably more that I don't know about!

Well, for starters, allocators. The standard library is now making adjustments around that, but it's not mainstream and most people don't use them and they don't get the same level of attention as the happy path.

However, Rust, the language has its issues on embedded.

Rust's ownership model is directly at odds with lots of embedded. These bits inside a register are owned by the ADC and these bits inside a register are owned by the DAC is not a happy thing in Rust.

Lack of arbitrary sized integers and how they slice.

Cargo. Quite annoying to deal with cargo and an embedded toolchain. The Rust embedded guys have done really good work if you're on ARM. If you're not, good luck.

That having been said, if you have to go implement something like Reference Counting in something not Rust, you will weep tears of blood debugging every single time your reference counts go wrong.

Embedded is engineering. It has tradeoffs. That's life.

I do not have as strong of feelings as your parent, but:

1. A lot of the APIs make use of the typestate pattern, which is nice, but also very verbose, and might turn many people off.

2. The generated API documentation for the lower level crates relies on you knowing the feel for how it generates the various APIs. It can take some time to get used to, especially if you're used to the better documentation of the broader ecosystem.

3. A bunch of the ecosystem crates assume the "I am running one program in ring0" kind of thing, and not "I have an RTOS" sort of case. See the discussion in https://github.com/rust-embedded/cortex-m/issues/233 for example.

Every time I play with embedded Rust I get this feeling that some of the people driving it are more into language esthetics and don't have experience in real-world embedded systems.

For example, I see inefficient patterns that are common in frontend world but have no place in an embedded system being promoted as "proper" way of doing things.

The other replies reflect my thoughts, so I don't have much to add. So, these are elaborations on those:

It appears most of the peripheral support libs (eg those that use Embedded-HAL traits) are not designed with practical ends in mind; I've found it easier for all I2C/SPI etc devices I've used to start from scratch with a `setup` fn with datasheet references, than DMA transfers. So, you have these traits designed to abstract over busses etc; they sound nice in principle, but are (so far) not useful for writing firmware.

I get a general sense that the OSS libs are designed with a "let's support this popular MCU/IC, and take advantage of Rust's type system and language features!" mindset. A bare minimum is done, it's tested on a dev board, then no further testing or work. There are flaws that show up immediately when designing a device with the lib in question.

So, at least for the publicly-available things, they're designed in an abstract sense, instead of for a practical case.

Which preprocessor do you recommend for writing C?

Zig has been able for a while now to compile to C code, which is part of our bootstrap procedure now, so you can compile that output with an appropriate C compiler and target whatever you want.

We do have plans for adding backends for unconventional targets eventually.

Marginal improvements add up.

Make it an optional crate like `no-std` is, where you specify it in your cargo.toml

While you are technically right, one area where the two are unlike is that you want to be polymorph with regards to async/non-async, while it is less often the case for error handling. That exact same sleep implementation, or db query should be usable both as an async call, as well as a blocking one and it is the caller that wants to decide that. Which is not trivial to do on the calling side from a language perspective as it then has to recursively decide the same for all its subcalls.

The new experimental languages with effect types might be able to give us the best of both as they actually expose what you are talking about as an abstraction at the type level. We will see.

The main difference to me is that Async/await tends to permeate your whole codebase. Once one part of the system is Async/await everything is. With Go I can write most of my code synchronously and maybe somewhere down the stack make 3 HTTP calls in parallel without having to change anything about the calling functions.

> not a struct like `Result`

Minor nitpick, but it's an enum.

https://github.com/rust-lang/rust/blob/master/library/core/s...

>> But Rust is not a language which can dictate its execution environment. It needs to be able to exist in a C-ish world, and that's not something that supports yielding. It's a shame, but at least you can write kernel modules in Rust.

Ada is also used in embedded and low-level environments where the execution environment can be limited. The way that Ada "gets around" such limitations is through language "annexes". Annexes are optional language extensions for specialized use cases:

https://www.cambridge.org/core/books/abs/programming-in-ada-...

http://www.ada-auth.org/standards/22rm/html/RM-1-1-2.html

Rust partially does this already with [no_std] (https://docs.rust-embedded.org/book/intro/no-std.html), so the concept is not too different.

That isn't quite true. An async signature forces it's caller to be async as well. This is because of it's semantics. Most signatures don't infect their callers signatures like that. async is qualitatively different in this regard.

I think Elixir is a bad example here because it's one of the eco systems that, while they preach "Use a function if you can!" very loudly, use macros much more heavily than other eco systems, often in places where they don't have to. Phoenix, the (unfortunate) flagship library, abuses macros all over the place where even relative beginners can see that they didn't need to (see [0] for example). It's incredibly badly designed overall and these things have set the tone (especially since a lot of Elixir programmers are in reality just Phoenix programmers).

So, while macros are "discouraged" in Elixir, in practice they are very much encouraged by several prominent libraries. Picking on Phoenix is very easy because it's so blatantly bad in this regard (and others) but it's almost impossible to do useful things with Ecto if you go outside the macro bubble, etc., as well.

Example that shows how an eco system that definitely could have done stuff with macros (Clojure) has correctly decided that writing functions that take data is better than using macros:

Elixir and `Plug.Router`:

    defmodule MyRouter do
      use Plug.Router
    
      plug :match
      plug :dispatch
    
      get "/hello" do
        send_resp(conn, 200, "world")
      end
    
      forward "/users", to: UsersRouter
    
      match _ do
        send_resp(conn, 404, "oops")
      end
    end

Clojure and `reitit` (https://github.com/metosin/reitit):

    (def router
      (r/routes
        [["/hello" {:get (fn [r] {:status 200 :body "world"})}]
         ["/users" {:name :users
                    :router users-router}]
         ["*" {:get (fn [r] {:status 404 :body "oops"})}]]))

P.S. I've used Elixir since 2015, this is not an opinion I've developed at a glance.

You know what they say about libraries; if you're not having problems, you're not using enough of them.

On a more serious note, "I want other people to write my code, but they're not following my standards" is rarely a sympathetic point of view.

Sorry if this is ignorant, but what’s the difference between async and concurrent? Is the problem that async schedules everything itself?

There can be both a "blessed" executor, while staying optional for such cases.

For example, Rust std lib has blessed Mutex. Even though these can't be used in the kernel, it is still good to have them in the std lib for >90% of normal crates.

Yeah I figured. Fragmentation by design.

Do you think all 1,000 people that Google referenced here are people who are pushing it into organizational adoption?

I agree the post could include more concrete metrics than self-assessment, but more than 1000 data points, even self-assessment data points, are usually not called anecdotes.

> Nobody, and maybe that’s my real point

To be honest, this is what I've taken away from this conversation so far: it doesn't seem like anything will satisfy your desires here.

> which is why I’d like some metrics to supplement the anecdotes

This conversation started with you not liking that the measure of quality is subjective, which is fine. How would you objectively measure code quality though? What metrics would you have preferred to see, other than the ones in this post?

This hasn't been my experience at all.

Me and all the other developers I know complain endlessly about the tools we're forced to use. We complain to anyone patient enough to listen, including all the engineering managers. No one I know ever got fired or laid off for this.

> Anecdata but I found myself very productive with Haskell when I was learning it for grad school, to the point where I knew that if it compiled, it was most likely right.

I recently told this to someone. The very next day my Elm code compiled just fine but it had three relatively tricky logical bugs which took me two hours to find and fix.

This was a rare enough occurrence that I remember it. Higher cosmic powers took note of my praise of strong typing and decided to teach me a lesson.

Big same. I remember being not being able to share a reference to something allocated on the stack at the start of main to a background thread. I was like "come on, of course its safe. That was allocated before the thread was spawned. It's main. When it returns the application exits"

But rustc's error messages helped it click that there might be a race condition on when the application returns from main and the background thread terminates. So it really needs to have the static life time to be safe. It's a small subtle thing but depending on the application it could lead to real bugs. I've definitely written variations of that bug in C before. A newer dev would have just accepted that flat out without arguing.

I've found Rust useful to study while I'm doing my primary job in C++.

A lot of the features Rust offers regarding traits and types can be emulated in C++ with templates, but the way C++ does it is far more obfuscated. Seeing the same thing implemented in Rust helped me wrap my head around what some complicated template nestings were doing ("Oh, this is implementing traits!") in our C++ code.

Python programmers love Rust: - Lots of compilation errors, but then the code does what it says - Fast! That gives an immediate benefit that people coming from C++ don't see.

Really? Coming from C++, learning Rust felt very natural and welcome because it put a name and a structure to the mental model I had been using to keep a semblance of sanity while doing C++. Maybe learning primarily with C++11 was a factor?

How do you build a data race safe language without taking on the restriction of immutable data (which is imo, a much worse and bigger tradeoff than the borrow checker)?

I actually really like the borrow checker as a tradeoff, I think it makes code much easier to understand and it makes all aliasing bugs impossible. The removal of aliasing bugs is I think an undersold benefit of using rust.

Please demonstrate a practical and memory safe systems programming language without borrowing.

I'd be delighted to see it, because right now I am not aware of any practical way to have memory safe regions without static tracking of borrowing from these regions. It's either that or runtime checking.

FWIW, I believe the person you are replying to means "paged" as in "an alert was sent to my pager at 3AM that the entire system is down and I need to wake up and fix it", not the paging in/out of memory.

At least you won't get paged due to some weird memory bugs. Yes, this happens quite frequently. Worse, it's usually not something local to a single change but interaction across seemingly safe changes.

> Which we seldom due on most C++ projects, we rather rely on binary libraries and build only our own code.

Depends on the project. Many commercial projects do vendor dependencies and build them too, because you can't rely on the OS version. Especially on Windows or with more niche dependencies.

Just compiling Boost takes 15 minutes - more than any Rust project I've ever compiled.

Not sure what you mean about multiple toolchains.

Not sure where you looking but any Rust tangential topic gets its share of Nirvana fallacies, "bypassing borrow checker" and other such fallacies.

Probably one of the biggest speed ups to your inner loop writing / running code is to use something like https://github.com/Canop/bacon/. I used a combination of the docs and GPT chats to increase my learning speed a lot.