Re: Rust in the OS?
On 3/15/2024 11:10 PM, Saurav Pal wrote: 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. That was my initial impression as well. Certainly no one wants to see Rust scattered all over the OS like explosive diarrhea. But I have had time to think more about it. I think that a better use of effort would be to re-implement Rust OS drivers in C than to implement Rust environmental support for smaller leaf functions. A C re-implementation would be a welcomed by all, would not add any OS build complexity or design complexity, and would only require one toolchain and debugger (for the OS), and no changes to the OS build system. As a bonus, the re-implemented C driver could probably be considered an original work and more easily incorporated as a true part of the OS* *Disclaimer: I am not an attorney.
Re: Rust in the OS?
*Rust was included in Linux would help On Sat, Mar 16, 2024 at 10:40 AM Saurav Pal 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 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 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 &g
Re: Rust in the OS?
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 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 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 > >
Re: Rust in the OS?
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 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 >
Re: Rust in the OS?
-1 from me for Rust in the kernel, +1 for Rust in apps. Pierre-Noël Bouteville Envoyé de mon iPhone > Le 14 mars 2024 à 09:51, raiden00pl a écrit : > > -1 from me for Rust in the kernel, +1 for Rust in apps.
Re: Rust in the OS?
-1 from me for Rust in the kernel, +1 for Rust in apps Mixing languages in the kernel was never a good idea. Kernel should follow "as simple as possible" philosophy whenever it could. My opinion is that although Rust is safer than C, if you know what you are doing, a C is good enough. If you don't know what you are doing, Rust is dangerous too. On Wed, Mar 13, 2024 at 7:29 PM Gregory Nutt 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. > > >
Re: Rust in the OS?
-1 from me for Rust in the kernel, +1 for Rust in apps. Sebastien and Tomek gave enough arguments to avoid Rust in the kernel. Not a technical argument from me: Rust has too many arrogant members in the community with a messianic approach (like `Rust will save embedded, blah, blah, blah`), it's quite irritating and bad for your mental health :) czw., 14 mar 2024 o 00:36 Tomek CEDRO napisał(a): > 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 >
Re: Rust in the OS?
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
Re: Rust in the OS?
No one said "full community support" or "unanimity". That would be nice. There are Apache rules for determining technical direction that defines "community support": https://www.apache.org/foundation/voting.html under "Code Modifications". This prohibits any small group from commandeering the technical direction of the project. Apache prohibits that and requires that any change must be at least acceptable to all voting members. That is the Apache way. On 3/13/2024 4:40 PM, Alan C. Assis wrote: I think we will never have "full community support" because it means something like "unanimity" and as a guy called Nelson Rodrigues once said: "All unanimity is dumb". Although (fortunately) we don't have full community support, it seems we have a direction: only application support for now. Best Regards, Alan On Wed, Mar 13, 2024 at 7:17 PM Gregory Nutt wrote: On 3/13/2024 4:11 PM, Alan C. Assis wrote: I think we are having a CMakefile deja-vu here, don't we? (I hope we don't lose any developer this time) Let's make sure that we have full concurrence from the community. Our responsibility is to serve the whole community and not just the special interests of a few. That is what it means to be an Apache project. The CMake effort did not have full community support. Let's make sure that we do this time.
Re: Rust in the OS?
I think we will never have "full community support" because it means something like "unanimity" and as a guy called Nelson Rodrigues once said: "All unanimity is dumb". Although (fortunately) we don't have full community support, it seems we have a direction: only application support for now. Best Regards, Alan On Wed, Mar 13, 2024 at 7:17 PM Gregory Nutt wrote: > > On 3/13/2024 4:11 PM, Alan C. Assis wrote: > > I think we are having a CMakefile deja-vu here, don't we? (I hope we > don't > > lose any developer this time) > > Let's make sure that we have full concurrence from the community. Our > responsibility is to serve the whole community and not just the special > interests of a few. That is what it means to be an Apache project. > > The CMake effort did not have full community support. Let's make sure > that we do this time. > >
Re: Rust in the OS?
On 3/13/2024 4:11 PM, Alan C. Assis wrote: I think we are having a CMakefile deja-vu here, don't we? (I hope we don't lose any developer this time) Let's make sure that we have full concurrence from the community. Our responsibility is to serve the whole community and not just the special interests of a few. That is what it means to be an Apache project. The CMake effort did not have full community support. Let's make sure that we do this time.
Re: Rust in the OS?
I think we are having a CMakefile deja-vu here, don't we? (I hope we don't lose any developer this time) The goal of improving Rust on NuttX is to get better support for our current "integration" (that is not implemented the right way, actually it is just a wrapper currently, we had a presentation from the Rustix author explaining the issues). So, the idea is just to get things prepared, in case in the future someone really needs to integrate some external driver implemented on Rust (who knows?). That is the initial propose (from 3 years ago) : https://issues.apache.org/jira/browse/NUTTX-5 If someone wants to improve it, please do it! Best Regards, Alan On Wed, Mar 13, 2024 at 6: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). >
Re: Rust in the OS?
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).
Re: Rust in the OS?
I am against Rust in NuttX core for the same reasons against Rust in FreeBSD core. These systems are minimalistic Unix, self sufficient, and maintainable. Lets keep things that way. We had long discussion about that recently on the BSD mailing list: https://lists.freebsd.org/archives/freebsd-hackers/2024-January/002823.html ps/2: All this Rust hype along with enforced changes ideologies seems like well coordinated viral marketing scam it happens wherever you look whether you want it or not and I will not say destructive until I can see independent standalone fully featured OS written only in Rust that will last for at least 5..10 years gaining popularity and user base otherwise its a marxist history rewrite on things that still work. You want Rust in the core go ahead write RustOS have fun maintaining it for 5 years and show us its better :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Wed, Mar 13, 2024, 19:29 Gregory Nutt 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. > > >
Re: Rust in the OS?
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 wrote: There is some discussion in Issue #11907 proposing to use the Rust language within the OS
Re: Rust in the OS?
I have mixed feelings too regarding Rust in the core OS. Having Rust aplications is in my oppinion the way to see how community feels about Rust. There is another aspect of having Rust in Nuttx. Who will maintain it after merge? Best regards Alin On Wed, 13 Mar 2024, 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 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. > > > > > > >
Re: Rust in the OS?
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 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. > > >
Rust in the OS?
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.
