ToaruOS With Kernel Written From Scratch Is Still In Development

[starshipeleven]

If it so hard not to create memory leaks, do not develop any software. Think of old home computers like C64, os and games were programmed with assembler and what a huge success. There is also newer os that is programmed with assembler.

Cool, now answer the question "why the newer OS programmed with assembler isn't also a huge success?".

[Luke_Wolf]

Well, Rust would break quite a number of his arguments. It's not object-oriented, it doesn't have exceptions, and it would solve a number of common C errors.

Just because it doesn't have explicit classes does not mean that Rust isn't object oriented. All OOP really means is creating models in code as opposed to simply writing algorithms to create solutions[1]. Designing models has a lot of overhead associated with it up front, and for one off programs it may not be worth it. However once you get into the range of a program being thousands of lines of code you are writing less code because OOP promotes code reuse in a way that non-OOP code can't provide. Furthermore by creating a discrete model with concrete units it's far easier to reason about and comprehend the code than if you just have a mess of functions.

Now that said is Rust a language designed to help you operate in OOP paradigms? Yes, actually. Its type system is a mutable graph as opposed to a static hierarchy, but talk is cheap... let's see some code (Note that I haven't checked to make sure any of this will compile or run, but the principles are there):

//rust
trait Animal{
    fn speak(&self) -> String;
    fn move(&self);
}
struct Dog{

}
struct Cat{

}

impl Dog{
    fn New() ->Dog{
        Dog{}
    }
}
impl Animal for Dog{
    fn speak(&self) -> String{
        "bark"
    }

    fn move(&self) {
    }
}
impl Cat{
    fn New() -> Cat{
        Cat{}
    }
}
impl Animal for Cat{
    fn speak(&Self) -> String {
         "meow"
    }
    fn move(&Self){
    }
}

//C#
public interface Animal{
    String speak();
    void move();
}
public class Dog{
    public  Dog()
    {
    }
    public String speak()
    {
         return "Bark";
    }
    public void Move()
    {
    }
}
public class Cat{
    public  Cat()
    {
    }
    public String speak()
    {
         return "meow";
    }
    public void Move()
    {
    }
}

Now what exactly is the difference between these two? Functionally nothing. From a modeling perspective, nothing. The only thing that differs is that semantically in Rust you seperate out the data from the methods from the methods implementing a specific interface, which makes the object system more flexible. Okay you might say... what about inheritance? well that's easy, just use composition like what happens under the covers.

struct GermanShepherd{
    _dog:Dog
}
impl GermanShepherd{
    fn New() -> GermanShepherd{
        GermanShepherd{ _dog : Dog::New()}
    }
impl Animal for GermanShepherd{
    fn Speak () -> String{
        "WOOF"
    }
    fn Move(){
        _dog.Move();
    }
}

Okay... Well what about Polymorphism? You can't derive classes so you can't have that right? Well... OOP best practices say to have functions rely upon interfaces as opposed to concrete classes, and we have interfaces with Traits and we have generics that have flexible where clauses, so this is doable:

trait Canine{
    fn dig(&Self);
}
impl Canine for Dog{
    fn dig(&Self) {
         println!("Digging a big old hole");
    }
}
impl Canine for GermanShepherd {
    fn dig(&Self) {
        _dog.Dig();
    }
}
fn DogFunction<T>(&dog: T) Where T: Animal + Canine{
    println!(dog.Speak());
}

Now is what I just wrote up in this post in any sense ideal code? Absolutely not, it's a contrived example to show a point that is standard but fairly crap in terms of what you would actually do. That said... it shows that it does in fact facilitate the OOP methodology. Does it look different? Oh absolutely it does, but nobody who understands OOP ever defined an "OOP Language" as have the class keyword, An "OOP Language" is simply one that facilitates writing code in an Object Oriented manner, which Rust does.


[1] Yes all programs are "simply algorithms" but it's a methodology difference

[cb88]

If you make errors with C, do not program.

If you think you can program in C without errors you are in fact in error already...

[computerquip]

If you make errors with C, do not program.

That's unfortunately not how the world works. You have to assume human error or you're going to set yourself up for failure.

[AsuMagic]

Waste of C programmers time, they should help ReactOS kill windows someday.

stop commenting, that's a time waste!

[Hi-Angel]

No, Torvalds is against the basic C++ features, C++14 isn't changing that.
Now grab some popcorn and read this (talking about C++ in git, but the same applies to kernel) http://harmful.cat-v.org/software/c++/linus

The relevant part:
In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap.

Now, I don't know Rust enough to extrapolate on his views, but he does have some very strict standards there.

Well, Rust would break quite a number of his arguments. It's not object-oriented, it doesn't have exceptions, and it would solve a number of common C errors.

[rabcor]

Rewritten kernel? Amazing.

And while I agree that maybe their time might be better spent on ReactOS, it's a different sort of project, they are circumwriting and re-writing the existing linux kernel with I assume a massive amount of backwards compatibility, ReactOS are shooting in the dark trying to guess at how to make the OS work like windows, it's harder, it's different, but even more amazing.

[starshipeleven]

Well, let's not make of Linus a hated in the nation.

No, Torvalds is against the basic C++ features, C++14 isn't changing that.
Now grab some popcorn and read this (talking about C++ in git, but the same applies to kernel) http://harmful.cat-v.org/software/c++/linus

The relevant part:
In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap.

Now, I don't know Rust enough to extrapolate on his views, but he does have some very strict standards there.

[tuuker]

Waste of C programmers time, they should help ReactOS kill windows someday.

[timofonic]

Last I heard, It was compatible with neither of existing drivers. It's a proof-of-concept. I'd rather expect (and I'd hope for it) that Linux kernel would start accepting Rust code. But it's nice to have a working kernel written in Rust, because it would be an important point in the discussion about Rust's place in the kernel.

Despite any requirements of Linux/Linus, there's a totally essential one: Actively maintained Rust backend for GCC on par with LLVM one at least.

I think Rust needs this ASAP in order to become more widespread.

There's one, but it's very WIP and totally abandoned over a year ago...

[rust-dev] Rust testsuite (October 23, 2013
GCC mailing list: Rust front-end to GCC (December 3, 2013)
LWN: A Rust frontend for GCC (December 3, 2013)
Phoronix: Mozilla's Rust Language Gets A GCC Compiler Front-End (December 3, 2013)
[url=https://github.com/redbrain/gccrs]GitHub: Rust Front-end to GCC (July 17, 2015)[url]

Some people say that Rust is the new LLVM, but Rust uses LLVM itself and no other compiler supports it...