ToaruOS With Kernel Written From Scratch Is Still In Development

[AsuMagic]

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

stop commenting, that's a time waste!

[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.

[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...

[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

[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?".

[Hi-Angel]

Luke_Wolf all of that is possible in Haskell — aren't you going to say that Haskell is object-oriented? The Wikipedia article for Rust for a reason doesn't mention OOP paradigm, Rust is mainly functional.

[starshipeleven]

Luke_Wolf all of that is possible in Haskell — aren't you going to say that Haskell is object-oriented? The Wikipedia article for Rust for a reason doesn't mention OOP paradigm, Rust is mainly functional.

Torvalds hates OOP (knowing java, I can't really disagree), anything that might be seen as/used as/facilitates OOP will trigger a FUCK YOU $language_name ! reaction.

Remember the above, "if we must use c++ but accept only c-like stuff we are better off using c period".

[hansg]

Phoronix. The site where the article never gives any interesting details (what is special about this OS? Why should we care? How does it perform compared to others?), and where every last discussion is immediately hijacked to become a rust-ad.

[Luke_Wolf]

Luke_Wolf all of that is possible in Haskell — aren't you going to say that Haskell is object-oriented? The Wikipedia article for Rust for a reason doesn't mention OOP paradigm, Rust is mainly functional.

If all of that is possible in Haskell, then absolutely yes. there's very few languages that aren't and you'd understand that if you actually understood what Object Oriented Programming is about. The requirement for a language being object oriented is as follows: Does it facilitate programming in an object oriented manner? To be explicit that is to say, does the language allow you to model a system or does it force you to simply implement an algorithm? if Yes, then yes. If No then no.

Object Oriented Programming languages generally, but aren't required to, support the following three features: Inheritance (Either through a class system or composable structures, or whatever), Polymorphism (Which in Modern OOP is basically always handled as relating to interfaces, which Traits are), and Encapsulation in a manner that is easily accessible to the developer. Javascript however is an example of an object oriented programming language that doesn't support encapsulation or the concept of polymorphism really, but it is entirely feasible to write Javascript in an object oriented manner (I certainly have), and well... you're playing around with a Document Object Model.

The only legitimate concern over OOP that I've ever seen, as opposed to "Waaaaah Newbies suck" is that OOP is very much big design up front. So for what would procedurally be a very small project can be substantially larger in the OOP paradigm when done right. However for large projects I've certainly found that rewriting procedural code into an OOP paradigm actually reduces the size and even if it doesn't reduce the size it absolutely reduces the complexity because it get's split into smaller more tightly defined code units. However even if we're talking a small project that would be much smaller done procedurally than OOP, if you intend to keep it around, there's a very strong argument that you should just go all the way from the beginning... the whole MVC enchilada because it'll make maintenance and extension easier later. It makes me quite happy when I can reduce the number of places I have to touch in code to be able to extend it down to 1 or 2 places (preferably loose coupled enough to be the main function and the configurator factory).

[Luke_Wolf]

(preferably loose coupled enough to be the main function and the configurator factory).

Actually on this note without OOP and Dependency Injection configuration files are a fucking pain to deal with.