*Rust was included in Linux would help On Sat, Mar 16, 2024 at 10:40 AM Saurav Pal <resyfer....@gmail.com> wrote:
> 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 >> > >> >
