Hi,

My position is : not in the core OS.

Why is everyone not surprised about that lol


I have actual Reasons for this, not just my bad mood or resistance to novelty:

-only one toolchain, no alternative

-this excludes anything not supported by vanilla clang, eg ARM/intel/riscv (I think). ez80/mips rust support anyone?

-the language is not mature, still evolving, no official standard exists

-it requires many bindings to pure "unsafe" C code anyway

-it is VERY complex to program with (more than C at least) and will require knowledge of both c and rust

I would say do as you wish in apps, but not in the core OS.

Even drivers would be problematic, drivers have to be portable to every platform we support, including the least common ones.

Sebastien


PS:  and you will have the temptation to use async/await code for "performance reasons", making the source as unreadable and unmaintainable as a modern ios app written in swift :-)

PS2: The same bindings and complexity problems would arise with any other "safe" language, like Ada. These are cool for apps and server stuff, but not that much for a low level operating system.


On 3/13/24 20:51, Nathan Hartman wrote:
tl;dr: I am in wait-and-see mode regarding Rust.

The long story:

I have been watching the programming language landscape for some time to
see if there is a viable successor to C/C++.

C has many advantages:

* Standardized (ISO and ANSI standards) since more than 30 years ago, which
makes the language very stable. Code that compiles and works today will
very likely compile and work tomorrow.

* Supported on all hardware.

* Supported by numerous compiler toolchains, free and proprietary.

* Supported by lots and lots of development tools of all kinds, such as
testing and analysis.

* Close to the hardware.

* Pretty much all operating systems and language interpreters are either
implemented in C or implemented in other languages that have a dependency
on C.

This (in addition to the Lindy Effect [1]) suggests to me that C will be
around and well supported for a long, long time to come.

C has only one disadvantage that I can think of, which is how easy it is to
make dumb mistakes that lead to big problems.

This one disadvantage is big enough that many people are searching for a
solution in the form of a new, safer programming language.

I personally don't think that Rust is necessarily "better" than C (I don't
think it's "worse" either). But AFAICT, if there is a language in
widespread use that could take over from C, it might be Rust. There is
significant interest in Rust and a lot of buzz about Rust around the
Internet. There is more than buzz. There is an ongoing effort to use Rust
in (isolated parts of) the Linux kernel, as well as the Windows OS. These
things are important because when it comes to choosing a language that
needs to be supported long term, widespread adoption is arguably the most
important factor.

The advantages of using Rust in the NuttX OS proper are, we hope, better
and safer code.

There would be some disadvantages also: Splitting the implementation
between C and Rust means:

* Needing to know both languages

* Dealing with the boundaries between the languages and whatever marshaling
needs to be done there

* To my knowledge, at this time Rust is *not* standardized by ISO or any
other standards organization, and the language is evolving, so we'd need to
deal with the incompatibility issues of tracking a specific version of the
language and possibly revisiting/rewriting code as new versions of Rust are
introduced. This may cause compatibility issues to our users. (Example:
What if their application is targeting a different version of Rust than
NuttX?)

I recently read an article on LWN about Rust in the Linux kernel. I think
it was the one at [2]. I highly recommend to read that if we're considering
Rust in NuttX to understand what some of the challenges might be, and to
learn how the Linux kernel devs are approaching that.

Back to my tl;dr about being in wait-and-see mode, I would like to see
standardization of the language by a recognized standards body before
adopting it for long-term use. That will indicate to me that the language
can be expected to stick around for a long time.

Also it will allow us to specify to what standard NuttX is written. We'll
be able to say NuttX is written to, say, Rust25 (or whatever the number
would be), the same way we say NuttX is written to C89.

Having said that, if the NuttX community wants to adopt Rust, provided it
is well discussed and the issues like evolving language are handled
somehow, I wouldn't oppose it. (But at this time, I'm not pushing for it.)

Hope this helps,
Nathan

[1]
https://en.m.wikipedia.org/wiki/Lindy_effect

[2]
https://lwn.net/Articles/952029/


On Wed, Mar 13, 2024 at 2:29 PM Gregory Nutt <spudan...@gmail.com> wrote:

There is some discussion in Issue #11907 proposing to use the Rust
language within the OS (vs Rust applications on a pure C OS).  If anyone
has any feelings, Pro or Con,  you should participate in this
discussion.  This kind of decision impacts the entire community and
should have the input of all of the community that has an opinion.



Reply via email to