Rust 1.0 released

The trickiest part would be inline functions. And I think Rust is also missing a simple way to wrap unions.

> Really, the only sane way to do it would be to either use a C stub to wrap all calls to macros or inline functions, or to somehow autogenerate the Rust equivalent from the kernel C structures, inline functions, and macros.
It should be possible to eventually create something like Go's "import C" feature, that allows to automatically wrap C code in native bindings. Perhaps even preserving inline qualifiers by using Clang to compile C blocks within Rust code.

That's a sizable amount of work, but it's _possible_. And in extreme, Rust can be used just like pure "C" - simply slap 'unsafe' qualifier on your code and go mad with raw pointers.

From what I see, right now Rust is the only major language capable of replacing pure C/C++ even for the most low-level tasks.

In any event, if the accepted practice for the Rust community is to simply ignore OOM, then that would suck. It's generally understood to be best practice in the Unix world for _libraries_ to always handle OOM. Applications can choose to abort or recover, but at least they have the choice.

One of the nice things I like working with Lua is that Lua can propagate OOM while maintaining VM consistency. That kind of attention to detail shows a concern for code correctness. Like Perl, Python, or Rust they could have punted, but they didn't. That means _I_ get to make the choice of how to handle OOM, based on the particular constraints and requirements of my project. And it means library authors who bothered to worry about OOM haven't wasted their time.

Obviously you can manage. But handling errors is one of the most fundamental and difficult aspects of programming, and for a so-called systems language like Rust to skip around it kinda sucks.

try!{}, unwrap, and the language features undergirding those idioms apparently came too late in development. Those features represent a compromise and resolution of internal disputes that could have changed the course of other aspects of the language and core types, as well as the standard library. For example, perhaps the Copy trait (which is part of the language reference, not the standard library) could have been amended to allow returning something like Result<T, E>, and a language construct added to inform the compiler of where to branch when copying failed.

Anyhow, at the end of the day it's the dude who _actually_ wrote parts of a _real_ operating system using Rust who lamented these deficiencies.

Said that, the language is interesting and might be usable for writing a kernel; would take a work, though, and not of advocacy/awareness raising kind.

[1] for some value of young - there is such thing as youthful maximalism seamlessly transitioning into senile dementia, so it's hard to estimate the chronological age...

I prefer to fail fast as a discipline. That means I always try make sure that at any point of failure--memory, thread-contended resource, data source (file, socket), etc--my state is consistent. Focus on keeping your state consistent and transparent, and everything else follows from that.

Whether I _actually_ fail fast in the end, or leverage some other technique (blocking, reserve pool, cache flushing, etc) is more of a policy decision. But if you rely on those other techniques from the outset, I think you'll tend to end up with messy and complex code. For one thing, those measures are leaky--blocking, reserve pools, and cache flushing all tend to create cross-component dependencies, at both the interface level and at run-time. A data sink allocating a buffer now needs to know about some other random component's caching interface, or it needs to share or duplicate a reserve pool. And in the end it might all be for naught. It's seeing that kind of complexity, I think, where people get the idea that handling OOM is impractical.

Plus, much like the phenomenon of buffer bloat, trying to hide resource exhaustion will often only compound the problem at the macro scale. Decisions on how to handle exhaustion are better handled at the edges, not by the actors in the middle. They can decide to fail or retry. The bulk of the software in the middle should simply be concerned with facilitating such decisions.

C++ needed noexcept to support move semantics on objects in containers, where moving can throw. In rust, moving is a much simpler operation, and can't fail. The consequences of declaring a Result return unnecessarily should be less than of failing to propagate noexcept on a C++ move constructor.

Since I gather most of the standard traits don't (yet?) allow for returning Result, it remains to be seen how deeply the discipline of comprehensive failure handling can penetrate. The reason to hope for improvement is that the rust community have routinely embraced changes that break every existing program. People are understandably reluctant, though, to wrap every statement in a try! block. Rust may be forced to accept a flavor of exception mechanism, which would be less onerous if it doesn't come with a demand for mannered "exception-safe" style.

To take your suggestion - splitting the application into pieces is a fine solution. But the small supervisor core which co-ordinates the pieces and is in charge of restarting them on failure must itself be robust, and cannot just die and be restarted - otherwise it's turtles all the way down... So there needs to be the possibility of writing code in a provably safe way, even if the amount of code that ends up being like that is quite small.