Linked by subterrific on Mon 9th Jan 2017 22:25 UTC
OSNews, Generic OSes

Rux's goal is to become a safe general-purpose microkernel. It tries to take advantage of Rust's memory model - ownership and lifetime. While the kernel will be small, unsafe code should be kept minimal. This makes updating functionalities of the kernel hassle-free.

Rux uses a design that is similar to seL4. While there won't be formal verification in the short term, it tries to address some design issues of seL4, for example, capability allocation.

The code is very approachable for anyone interested in capability-based microkernel design.

Permalink for comment 639532
To read all comments associated with this story, please click here.
Member since:


You miss my point. At some point in the future, languages like D, Swift, Rust and Go will have systemic recurring problems with their existing codebases.

I don't understand why it means we should stick with C++, which has even more crust, indefinitely? That's not a good plan for many of us.

If today's languages are looking long in the tooth (to borrow from RobG) in the decades to follow, then by all means I hope they do build something even greater yet. This shouldn't hurt our pride, on the contrary the goals they set for themselves in the future will largely depend on the goals we set for ourselves today, which depend on what we've already achieved with C++ and Ada and Pascal all those years ago and even further back to Babbage and Pascal. The evolution of human ingenuity is a beautiful thing.

You think I don't know Stroustrup's views on the matter. He's one of the biggest pushers, still, of modernizing C++ with better features and leaving old ones behind.

That's what D-lang did for the most part. C++ itself faces a major conundrum, it's huge base of legacy code that keeps it popular is also responsible for holding it back. Sometimes to make progress past the local maxima, you have to fundamentally break some of the scaffolding that keeps you stuck there.

Don't mischaracterize it.

I simply was not convinced by your arguments and counter-examples in that discussion. You tried to make it sound like Rust does theorem proving for thread correctness, when in fact all it does is formalize and lock down ownership semantics. That's not taking offence.

I gave examples where rust provided better safety semantics than C++. Anyways I'm not going to revisit that fruitless thread, if you believe that C++ is just as safe as rust, then in the interests of a keeping things lighthearted, then I'll just accept it and move on and I ask that you do the same ;)

Languages will get big, bloated, and accrue cruft. No language is exempt. Until a language designer and community grows up and accepts this, and is willing to support the language with all its warts like Stroustrup does with C++ and the Ada guys with Ada (you could even say the same about HTML and Javascript, in a perverse way ;) ), their language is a fad language.

But that line of reasoning just seems arbitrary and relative. Obviously C++ had a beginning too. Calling something a "fad" now just because it's new doesn't convey anything meaningful at all about merit and just sounds condescending towards a group of professional developers who are genuinely working hard to advance the state of software engineering.

Maybe, and let's hope, Rust's designers and its community are mature enough to stick with Rust regardless of how much garbage it accrues over the years.

But why? Tech gets ditched all the time once it's outlived it's usefulness, and not just software.

In the video Stroustroup says "C++ is obviously too large."

The facebook engineer says of C++'s compilation efficiency problems "I think it's a problem intrinsic to c++. C lang was designed with batch multi-stage processing in mind, and it shows. All these companies share the same problems and that have a huge c++ code base. Have a huge army to babysit the build system, at the end of the day it was an unsolvable problem. No amount of money can make c++ compile fast."

The google engineer says "we measured data went to the compiler. 4.2million factor blow up when using class per header file."

C++ will remain useful to many people for a long time, that's fine. But there are many companies and individuals who are frustrated with it and I find it very hard to make a case that they should not embracing new languages. For many of us, languages that carry the burden of legacy cruft is not a good option. There's no reason different people with different programming language opinions can't co-exist, just look at mainframers. Diversity is the spice of life ;)

Reply Parent Score: 2