Hi, I think some of the reasons why Rust was included in Rust would help.
*Pros*: - Memory safe if used correctly. - A central toolchain like cargo (some might consider it as a con, but it's easy to attract new blood if they don't have to learn an entire new toolchain for a project). - As Linus pointed out, more and more new and young developers are learning Rust, especially compared to C (I might be an exception here). The Lindy effect (as mentioned by Nathan) is valid for C, but Rust adoption is increasing, especially as many industries (including MS) are openly discouraging C/C++ in favor of Rust, which might cause a reduction in C programmers in the long term compared to Rust. Having low level programmers united from both worlds could be a great addition. - Unsafe parts are specifically marked, so if used in limit, easier debugging. - Memory bugs are probably the most time consuming bugs, especially for cases like race conditions. Logic bugs are easier to debug. The compiler is a bit too good at catching them and suggesting changes. - Pretty fast execution speed, almost comparable to C. *Cons*: - Rust is complex. TOO complex. It looks like the way C++ did. C++ tried to be a "better C" with some additional features and then to support its additional elements, it added something else, and so on till we get the modern C++ which is horrendous. Rust gives off an uncanny resemblance to it, especially since C is a time tested language that has shown it does not need too much. C is not perfect, but any attempt to make it perfect deteriorates it further. - Rust is too young. It's too dynamic. It changes too often. Every patch brings in new features. It's a pain. I would agree on version locking for this one, but there might be security problems as bugs and new implementations that break the new features are constantly being found especially as it's a young language. - Rust foundation is bad. - The compiler is good, but it takes a LOOONG time. - As Greg mentioned about POSIX compliance and C wrappers, any use of Rust deep inside the kernel would cause issues. All in all, I am *against* Rust being introduced in the kernel. However, I am fine with the language being in the very leaf nodes. Like some drivers, userspace applications, or userspace filesystems (FUSE)... especially those that only interact with the kernel over a fixed interface, and are not depended on by anything other than its own subprogram in the kernel. This will ensure Rust developers can write support for, say, their own boards, etc. While no C developer could work on that code later, having that code in the first place would be better than not having it imo. Regards, SP On Thu, Mar 14, 2024 at 7:24 PM Alan C. Assis <acas...@gmail.com> wrote: > I think there is a reference project that we can use as base: > > https://github.com/tylerwhall/zephyr-rust > > It doesn't seem to implement the drivers or anything else in the kernel. > > Best Regards, > > Alan > > > On Wed, Mar 13, 2024 at 8:36 PM Tomek CEDRO <to...@cedro.info> wrote: > > > On Wed, Mar 13, 2024 at 10:03 PM Gregory Nutt wrote: > > > On 3/13/2024 2:42 PM, Tomek CEDRO wrote: > > > > You want Rust in the core go ahead write RustOS have fun maintaining > > it for 5 years and show us its better :-) > > > > > > You are probably right in that. It would probably be necessary have to > > > be a different OS if any extensive amount of Rust is used. POSIX > > > defines a C interface to the OS with C function prototypes and C data > > > types. I haven't looked at this carefully, but a significant use of > > > Rust might jeopardize POSIX compatibility (or require a mess of C > > > conversion wrappers). It would probably be better to have a pure > RustOS > > > with a non-POSIX, but POSIX-like OS interface. > > > > > > I am not a language chauvinist, but I think we should avoid the > > > complexity and maintenance issues of a mixed language solution (as > > > enumerated by others in this thread). > > > > I can see Lup is already on the GH thread this is good news :-) I > > would suggest to limit Rust for the Application part and see how it > > works.. just as we have Basic, Python, Lua, Zig, etc working on top of > > existing untouched POSIX RTOS architecture.. then create several demos > > using display sound etc to show others how to port Rust applications > > to NuttX :-) > > > > > > Below are my concerns in depth for our internal discussion.. maybe you > > have similar thoughts.. and you can safely ignore that part :-) > > > > There are some Rust based OS already out there. Look how many! Some of > > them does not even plan to support security mitigations, sensor > > devices, BLE, WIFI, etc. Why? How does setup of those Rust OS SDK > > compares to current NuttX environment setup and build times?? > > > > https://github.com/flosse/rust-os-comparison > > > > Instead of injecting unimaginable maintenance nightmare into existing > > minimalistic projects Rust fans can simply focus on building new > > alternative solutions and prove these are better in practice - by > > results - they need to build commercial products on top of their OS, > > ship it, maintain it, take full responsibility for the results, after > > some years we will see how it works. I will be first to congratulate > > and buy a good Open-Source based Rust product. But right now that push > > for injecting Rust into all possible OS/RTOS seems really suspicious > > not to say viral and dangerous!! > > > > Lup can do magic with NuttX like running applications written in other > > programming languages and convert NuttX code to different programming > > languages in order to run on new platforms and environments. All is > > done in non-invasive way, respecting current architecture and backward > > compatibility, adding new functionality that is optional and diamond > > clean in maintenance. This is the only way to go! :-) > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > >
