Rust for OS dev

Is rust actually good for OS development, or should people just stick to C and assembly; This guy made a tutorial on how to create one and it caught my interest https://os.phil-opp.com/(USER WAS WARNED FOR THIS POST, You should always elaborate on your opinions rather than just spilling the soykaf.)

I wouldn't write a bootloader or a microkernel in rust, but it's probably good for user space.

>>39426 So just sticking to C is better, truly the greatest language of all time

The Linux kernel has been implementing Rust code into it since 2019 and Pop! OS is implementing a desktop environment called COSMIC that is written in Rust. Rust is one of the more energy efficient languages and fast enough so it should be good to go.

>>39428 The problem is that it is a fairly new language compared to C and assembly which means less documentation (the rust book is amazing)

>>39429 True but you'd never know till someone tries and running into walls could be used as example to influence development of Rust.

>>39431 The language has huge potential, being able to use the same language in OS, Malware and even Web dev, and the Ownership thing is a really good solution for memory

>>39428 > Rust is one of the more energy efficient languages. So is C/++. It's not like we're using java for operating systems (anymore). If there's anything that gives it an advantage, it'd be the tight error tolerances during compilation avoiding *most* major pitfalls. As for Cosmic, I suppose we'll have to see how that goes. Given their preferenced towards using Iced for their UI as opposed to more widely supported libraries like Qt and GTK, the desktop is probably going to be a mess for a long time. GNOME already struggles with Qt theming quite often, can't imagine trying to get both Qt and GTK lookin even remotely native on Cosmic is gonna be a quick job.

>>39435 >so is C++ Energy wise is a bit behind Rust which itself is only very slightly behind C. Rust is also a bit faster than C++. Only advantage C++ has over rust aside from being older in this study was a small reduction in memory usage. Of course this differs depending on task at hand. Brief https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/ The paper https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf Updated results. They added Julia to results. Too bad they didnt test even more languages including more obscure ones. https://archive.is/RtzQV

>>39433 >the Ownership thing is a really good solution for memory Yes, but it is not great for writing a memory allocation routine. >>39436 Important to note that energy waste is almost always caused by how you design your program, not what language you write it in. Inefficient algorithms are inefficient in every language and with every compiler. Where a language can help is by not hiding complexity or by providing good primitives for writing efficient code.

>>39437 Is there an easy way to avoid inefficiency or does it actually take effort to not be efficient?

>>39436 Ahh the infamous study, Consider forth. >>39425 C makes sense in the context of *nix operating systems. Maybe consider lisp for operating system development. Forth has also been hisotrically very good for this given that it's basically an abstract of assembly that can grow itself (c is not. Your forth is an os that lives on chips themselves and can compile new words as it goes).

>>39439 >consider forth what about forth? Why would one expect jumpcode to be more efficient than an optimizing compiler?

>>39441 Yeah because power efficient forth doesn't exist.... https://www.greenarraychips.com/ I also forgot all forth compilers are equal in optimization, and should be not considered.... On a side note about efficiency, Rust code isn't on it's very nature faster, if you work with Rust the compiler can produce fast code, but a lot of the natural ways to work with it will result in a lot of extra cloning which can make the code more inefficient and slower than say a CL compiler. The general lack of interactive tooling also makes it harder to see and optimize problems. Better system understanding leads to better ways to optimize the system one is working on with less time needed to achieve such results. As a tangent, I know when I worked with rust I couldn't use develop code on airplanes since the rust (language) compiler is a batch compiler. I always do develop lisp programs when I travel as the energy draw of incremental/interactive compilers/languages makes the energy draw of development much less wasteful.

>>39442 What about Ada as part of an OS?

>>39443 You can use whatever you want for OS development. Lisp and Smalltalk machines exist and did well for their time. When C was used for Unix people thought they were crazy as you have to use a low level language like assembly! We just decided to stop at C in mainstream culture as we are all now stuck on *nix. Generally speaking any interactive language platform is acting like an operating system, just using the underlying real OS as the hardware. See how Symbolics talked about operating systems: http://bitsavers.trailing-edge.com/pdf/symbolics/software/genera_8/Genera_Concepts.pdf

>>39442 Greenarrays chips implement a forth-like machine language in hardware. Comparing ISA's is pretty much meaningless due to implementation differences (with the exception of greenarrays, where there is only one implementation), and comparing specific chips is obviously outside the scope of programming languages. >I also forgot all forth compilers are equal in optimization, and should be not considered.... A high quality optimizing compiler for just about any language is just about equal to any other, assuming competent performance engineering for your code. What about forth makes it naturally more efficient? What about the 'classic forth' that everybody implements themselves?

OP just look at Redox. Not very useful as is but it's something to look at the code.

>>39438 It's complex. A lot of inefficiency in compiled languages can come from the compiler being unable to ensure invariants. The memory space is shared and the value could change halfway, it cannot guarantee that two pointer ranges do not overlap, the types used require checked integer overflow, code inlining leading to the executable spanning multiple pages, virtual functions... Then there's platform-related issues like branch prediction - if you know that a check could fail in 0.01% of cases, it might be more efficient to keep processing and check at the very end than spend every other cycle asserting that the condition is still true. Also some languages allow liberal amounts of UB, which could directly result in inefficient code or lead to fewer invariants being met.