Would it be possible to have this lifetimes/borrowing stuff in a scripting language?
Like, I care about who owns something, but I don't care about what something is?
For instance, you can't just have all your objects be some opaque thing, you need to know if it holds borrows into other types. On one end you can certainly do runtime checking (basically everything is a RWLock) which is slow and still just crashes at runtime. Or you can maybe do whole-program analysis (slow, weird non-local errors).
As far as I can tell, Rust strikes a really clean balance for region systems. Everything about signatures needs to be declared, and the rest can be locally inferred. But when you use type erasure (runtime vtable-based dispatch) you need to decide whether the erased objects are allowed to contain borrows, and what they borrow, upfront.
These things are essential if you don't have a GC but have a way to free memory, because the bugs they prevent would result in accessing reading or writing memory at invalid addresses.
That's not a problem with a GC, but they are still very useful because they prevent these issues that cannot be statically prevented in Java/JavaScript:
- Exceptions due to one part of the program manipulating a data structure while another is accessing it: the canonical example is someone iterating a dictionary while something else mutates it
- The program keeping a reference to mutex-protected data after unlocking the mutex
- Two threads manipulating the same object, causing races
- Something accessing a File that is closed, or in general a type in an unexpected state (this is because with a GC you can't "destroy" the previous object, but merely set it to a "closed" state that you can't statically check)
- Exceptions due to null pointers
So in general Rust is a safer language than Java, JavaScript and languages equivalent to them.
Rust is intended for performant, close-to-the-metal (hence the name) programming, so mandatory GC/RC won't cut it, but a single-threading restriction won't cut it either. And I think the way the borrow system implicitly gives you all the properties needed for thread-safety is one of the best things about Rust's design.
http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht...
https://medium.com/@tomaka/the-glium-library-5be149d87dc1
https://blog.mozilla.org/research/2014/08/26/javascript-serv...
Seems like this would go against the nature of scripting languages.
How does one design something to be well documented?
1. Ensure you have the tooling to produce nice docs.
2. Build time to write docs into your planning.
3. Actively try to find people who will write good docs.
4. Focus on making your code understandable, so that the
eventual docs will make sense. Spaghetti code is hard
to document.Pedantism aside, I guess it was a phrasing issue.
Though obviously in this case it was ambiguous punctuation.
I meant that I would like it to be well documented, not that it would be designed around documentation.
Yikes!!!
I'm waiting for OS development to start up in rust as it is clearly the better choice then C/C++ for a kernel.
I'm not saying Redox is the next Linux. But big things come from small beginnings, and good engineers are intensely aware of the limitations of their creations.
"I do, however, have a plan. I will make all applications run in Ring 3. I will do malloc and free through syscalls. I will move significant pieces of functionality into userspace libraries (a new libredox). I will use file numbers to identify file descriptors, and create read/write/seek/close syscalls. I will document the syscalls interface, provide more example programs, including programs that test the correctness of the implementation."
So the creator is aware of and wants correct those issues.
It is probably easier to do all of the massively unsafe things required to initialize in C than it is in Rust. Then Rust is just used after C does its dirty things.
C is a third party possibility, I allow C programs to run on Redox.
unsafe is a necessary escape hatch, but the temptation to use it to write C-style code is strong.
Out of curiosity, are you modeling this on an existing code base/architecture, or is this a new design?
Additionally, if doing clean-slate, might be worth looking into alternative models for constructing or securing OS's. EROS security OS, SPIN OS's type-safe linking for acceleration, Minix 3's reliability scheme, JX OS's architecture, Microsoft's verified VerveOS scheme, maybe even Amoeba distributed OS just for kicks to see what it could do today. Lot of stuff that might be better than Linux model with a Rust implementation in terms of reliability, security, extensibility, or developer productivity.
Just a thought for Redox author or someone else wanting to try an OS in Rust. However, best thing to come out of Redox project, imho, isn't the OS so much as this article:
https://redox-os.org/index.php?controller=post&action=view&i...
Great write-up on an equally great strategy of developing with hardware that's well-supported by both native OS's and virtualization. That's worth copying and expanding in other projects. Maybe worth a dedicated list like the HCL's where there's a list of computer builds that are easiest to develop on with or without virtualization. Or list it one piece of hardware at a time.
Looks like a great toy for making all sorts of single-purpose devices/terminals -- not just testing OS kernels.
To start, this wasn't supposed to be public yet. I was preparing cleanup before release, and I hope it is not seen as complete.
I am excited to see how much attention this has gotten, and I would be willing to answer any questions about Redox, how to use it, and how to contribute.
I have a blog at https://redox-os.org/ where I recently posted screenshots.
We can IRC at irc.mozilla.org #redox