[obviouslynotme]

A lot of C's popularity is with how standard and simple it is. I doubt Rust will be the safe language of the future, simply because of its complexity. The true future of "safe" software is already here, JavaScript.

There will be small niches leftover:

* Embedded - This will always be C. No memory allocation means no Rust benefits. Rust is also too complex for smaller systems to write compilers.

* OS / Kernel - Nearly all of the relevant code is unsafe. There aren't many real benefits. It will happen anyways due to grant funding requirements. This will take decades, maybe a century. A better alternative would be a verified kernel with formal methods and a Linux compatibility layer, but that is pie in the sky.

* Game Engines - Rust screwed up its standard library by not putting custom allocation at the center of it. Until we get a Rust version of the EASTL, adoption will be slow at best.

* High Frequency Traders - They would care about the standard library except they are moving on from C++ to VHDL for their time-sensitive stuff. I would bet they move to a garbage-collected language for everything else, either Java or Go.

* Browsers - Despite being born in a browser, Rust is unlikely to make any inroads. Mozilla lost their ability to make effective change and already killed their Rust project once. Google has probably the largest C++ codebase in the world. Migrating to Rust would be so expensive that the board would squash it.

* High-Throughput Services - This is where I see the bulk of Rust adoption. I would be surprised if major rewrites aren't already underway.

[aw1621107]

> No memory allocation means no Rust benefits.

This isn't really true; otherwise, there would be no reason for no_std to exist. Data race safety is independent of whether you allocate or not, lifetimes can be handy even for fixed-size arenas, you still get bounds checks, you still get other niceties like sum types/an expressive type system, etc.

> OS / Kernel - Nearly all of the relevant code is unsafe.

I think that characterization is rather exaggerated. IIRC the proportion of unsafe code in Redox OS is somewhere around 10%, and Steve Klabnik said that Oxide's Hubris has a similarly small proportion of unsafe code (~3% as of a year or two ago) [0]

> Browsers - Despite being born in a browser, Rust is unlikely to make any inroads.

Technically speaking, Rust already has. There has been Rust in Firefox for quite a while now, and Chromium has started allowing Rust for third-party components.

[0]: https://news.ycombinator.com/item?id=42312699

[1]: https://old.reddit.com/r/rust/comments/bhtuah/production_dep...

[jitl]

The Temporal API in Chrome is implemented in Rust. We’re definitely seeing more Rust in browsers including beyond Firefox.

[johncolanduoni]

> Google has probably the largest C++ codebase in the world. Migrating to Rust would be so expensive that the board would squash it.

Google is transitioning large parts of Android to Rust and there is now first-party code in Chromium and V8 in Rust. I’m sure they’ll continue to write new C++ code for a good while, but they’ve made substantial investments to enable using Rust in these projects going forward.

Also, if you’re imagining the board of a multi-trillion dollar market cap company is making direct decisions about what languages get used, you may want to check what else in this list you are imagining.

[pjmlp]

Unless rules have changed Rust is only allowed a minor role in Chrome.

> Based on our research, we landed on two outcomes for Chromium.

> We will support interop in only a single direction, from C++ to Rust, for now. Chromium is written in C++, and the majority of stack frames are in C++ code, right from main() until exit(), which is why we chose this direction. By limiting interop to a single direction, we control the shape of the dependency tree. Rust can not depend on C++ so it cannot know about C++ types and functions, except through dependency injection. In this way, Rust can not land in arbitrary C++ code, only in functions passed through the API from C++.

> We will only support third-party libraries for now. Third-party libraries are written as standalone components, they don’t hold implicit knowledge about the implementation of Chromium. This means they have APIs that are simpler and focused on their single task. Or, put another way, they typically have a narrow interface, without complex pointer graphs and shared ownership. We will be reviewing libraries that we bring in for C++ use to ensure they fit this expectation.

-- https://security.googleblog.com/2023/01/supporting-use-of-ru...

Also even though Rust would be a safer alternative to using C and C++ on the Android NDK, that isn't part of the roadmap, nor the Android team provides any support to those that go down that route. They only see Rust for Android internals, not app developers

If anything, they seem more likely to eventually support Kotlin Native for such cases than Rust.

[johncolanduoni]

> Unless rules have changed Rust is only allowed a minor role in Chrome.

I believe the Chromium policy has changed, though I may be misinterpreting: https://chromium.googlesource.com/chromium/src/+/refs/heads/...

The V8 developers seem more excited to use it going forward, and I’m interested to see how it turns out. A big open question about the Rust safety model for me is how useful it is for reducing the kind of bugs you see in a SOTA JIT runtime.

> They only see Rust for Android internals, not app developers

I’m sure, if only because ~nobody actually wants to write Android apps in Rust. Which I think is a rational choice for the vast majority of apps - Android NDK was already an ugly duckling, and a Rust version would be taken even less seriously by the platform.

[pjmlp]

That looks only to be the guidelines on how to integrate Rust projects, not that the policy has changed.

The NDK officially it isn't to write apps anyway, people try to do that due to some not wanting to touch Java or Kotlin, but that has never been the official point of view from Android team since it was introduced in version 2, rather:

> The Native Development Kit (NDK) is a set of tools that allows you to use C and C++ code with Android, and provides platform libraries you can use to manage native activities and access physical device components, such as sensors and touch input. The NDK may not be appropriate for most novice Android programmers who need to use only Java code and framework APIs to develop their apps. However, the NDK can be useful for cases in which you need to do one or more of the following:

> Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations.

> Reuse your own or other developers' C or C++ libraries.

So it would be expected that at least for the first scenario, Rust would be a welcomed addition, however as mentioned they seem to be more keen into supporting Kotlin Native for it.

[saghm]

> No memory allocation means no Rust benefits

There are memory safety issues that literally only apply to memory on the stack, like returning dangling pointers to local variables. Not touching the heap doesn't magically avoid all of the potential issues in C.

[scq]

Rust is already making substantial inroads in browsers, especially for things like codecs. Chrome also recently replaced FreeType with Skrifa (Rust), and the JS Temporal API in V8 is implemented in Rust.

[juliangmp]

> Embedded - This will always be C. No memory allocation means no Rust benefits. Rust is also too complex for smaller systems to write compilers.

Embedded Dev here and I can report that Rust has been more and more of a topic for me. I'm actually using it over C or C++ in a bare metal application. And I don't get where the no allocation -> no benefit thing comes from, Rust gives you much more to work with on bare metal than C or C++ do.

[gbin]

In robotics too.

[Aurornis]

> No memory allocation means no Rust benefits.

Memory safety applies to all memory. Not just heap allocated memory.

This is a strange claim because it's so obviously false. Was this comment supposed to be satire and I just missed it?

Anyway, Rust has benefits beyond memory safety.

> Rust is also too complex for smaller systems to write compilers.

Rust uses LLVM as the compiler backend.

There are already a lot of embedded targets for Rust and a growing number of libraries. Some vendors have started adopting it with first-class support. Again, it's weird to make this claim.

> Nearly all of the relevant code is unsafe. There aren't many real benefits.

Unsafe sections do not make the entire usage of Rust unsafe. That's a common misconception from people who don't know much about Rust, but it's not like the unsafe keyword instantly obliterates any Rust advantages, or even all of its safety guarantees.

It's also strange to see this claim under an article about the kernel developers choosing to move forward with Rust.

> High Frequency Traders - They would care about the standard library except they are moving on from C++ to VHDL for their time-sensitive stuff. I would bet they move to a garbage-collected language for everything else, either Java or Go.

C++ and VHDL aren't interchangeable. They serve different purposes for different layers of the system. They aren't moving everything to FPGAs.

Betting on a garbage collected language is strange. Tail latencies matter a lot.

This entire comment is so weird and misinformed that I had to re-read it to make sure it wasn't satire or something.

[goku12]

> Memory safety applies to all memory. Not just heap allocated memory.

> Anyway, Rust has benefits beyond memory safety.

I want to elaborate on this a little bit. Rust uses some basic patterns to ensure memory safety. They are 1. RAII, 2. the move semantics, and 3. the borrow validation semantics.

This combination however, is useful for compile-time-verified management of any 'resource', not just heap memory. Think of 'resources' as something unique and useful, that you acquire when you need it and release/free it when you're done.

For regular applications, it can be heap memory allocations, file handles, sockets, resource locks, remote session objects, TCP connections, etc. For OS and embedded systems, that could be a device buffer, bus ownership, config objects, etc.

> > Nearly all of the relevant code is unsafe. There aren't many real benefits.

Yes. This part is a bit weird. The fundamental idea of 'unsafe' is to limit the scope of unsafe operations to as few lines as possible (The same concept can be expressed in different ways. So don't get offended if it doesn't match what you've heard earlier exactly.) Parts that go inside these unsafe blocks are surprisingly small in practice. An entire kernel isn't all unsafe by any measure.

[tayo42]

Rust isn't that complex unless your pulling in magical macro libraries or dealing with things like pin and that stuff,which you really don't need to.

It's like saying python is complex becasue you have metaclasses, but you'll never need to reach for them.

[throwaway2037]

    > Rust is also too complex for smaller systems to write compilers.

I am not a compiler engineer, but I want to tease apart this statement. As I understand, the main Rust compiler uses LLVM framework which uses an intermediate language that is somewhat like platform independent assembly code. As long as you can write a lexer/parser to generate the intermediate language, there will be a separate backend to generate machine code from the intermediate language. In my (non-compiler-engineer) mind, separates the concern of front-end language (Rust) from target platform (embedded). Do you agree? Or do I misunderstand?

[qalmakka]

> Embedded - This will always be C. No memory allocation means no Rust benefits. Rust is also too complex for smaller systems to write compilers.

Modern embedded isn't your grandpa's embedded anymore. Modern embedded chips have multiple KiB of ram, some even above 1MiB and have been like that for almost a decade (look at ESP32 for instance). I once worked on embedded projects based on ESP32 that used full C++, with allocators, exceptions, ... using SPI RAM and worked great. There's a fantastic port of ESP-IDF on Rust that Espressif themselves is maintaining nowadays, too.

[j16sdiz]

> The true future of "safe" software is already here, JavaScript.

only in interpreter mode.

[sunshowers]

JavaScript does not have a separation between & and &mut.