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 (vs Rust applications on a pure C OS). If anyone
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.
