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.

Thread beginning with comment 639532
To view parent comment, click here.
To read all comments associated with this story, please click here.
Alfman
Member since:
2011-01-28

kwan_e,

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

kwan_e Member since:
2007-02-18

I don't understand why it means we should stick with C++,


I didn't say that. As I said before, the point I'm making for this discussion is about the willingness to stick with a language when it does develop cruft. Rust is no exception to cruft.

which has even more crust, indefinitely? That's not a good plan for many of us.


If you're starting new projects in C++, why would you use the crufty features especially if it costs nothing to exclude them?

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.


You were talking about developing a rustlang economy that could potentially take over the current ones (namely C and C++). That won't happen if people keep abandoning a language every time it gets difficult.

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

I'm not saying they're definite fads. But I think they're more likely going to gain fad status in a few years time. The difference with languages like Ada (I'm going to stop using C++ as an example since you seem to focus too much on it and not the general point I'm making) is that, yes, it was once a new language. But the community around it continued with it through its own missteps or unwieldiness.

I also don't agree that all language designers are advancing the state of software engineering. Most languages are just to fix the syntax peeves of some developers and contribute nothing.

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

Because you can't build a rustlang economy if there is no momentum behind rustlang.

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 ;)


Then by that reasoning, there is no such thing as a good option. All languages will develop legacy cruft, and new languages will reinvent old cruft. I have no problems with diversity in programming languages. And while you seemed to want to continue with discussing C++, I'll have you note my first few comments did not mention C++ at all.

Reply Parent Score: 2

ssokolow Member since:
2010-01-21

I didn't say that. As I said before, the point I'm making for this discussion is about the willingness to stick with a language when it does develop cruft. Rust is no exception to cruft.


What you don't seem to be acknowledging is that Rust has several things going for it that other languages didn't.

First, a brief overview of some of the languages I remember you mentioning, to point out the especially noteworthy problems they had:

1. Ada lost out to C because, for far too long during the critical time period, it was much easier and cheaper to get an acceptable-quality C compiler and learning resources.

2. D lost its opportunity because it misjudged the role of GC in the direction things were going, Sun Microsystems threw a ton of marketing money at Java, and it's STILL recovering from that "originally proprietary, resulting in a bifurcated community" issue.

3. Node.JS is more or less the definition of a fad language/environment/framework. Aside from letting client-side JavaScript developers try their hand a server-side coding without learning a new language, its strengths (an architecture and libraries/frameworks for lightweight persistent connections and betting on "NoSQL" in the ecosystem) are reasonably easy to retrofit to other languages while it still has the same major weaknesses (eg. no mature Rails/Django-level frameworks with mature SQL ORMs, schema migration, communities, etc.) even after Rails and Django have more or less caught up. Is it any wonder that polyglot programmers started to bleed back to platforms with the more comprehensive ecosystems? (It didn't help that, in many prime use cases, such as document-oriented JSON storage and querying, SQL databases like PostgreSQL also overtook the "NoSQL" databases at their own game.)

3. Outside of Japanese products like RPG Maker, Ruby never really outgrew the niche it captured by being first to market with Rails... but it's still holding strong with Rails. (I could never get over Ruby's warts in the first place, but I'll readily acknowledge that.)

I'll acknowledge that Go and Swift might be fad languages, given that they feel like the "Web 2.0" of the Java and C# world, but Rust actually has a long list of noteworthy advantages that, taken together in a single package, make it quite unique and compelling:

1. Cargo provides a build system and package manager that matches or exceeds every other mainstream language's offering.

2. The community so far is welcoming, engaged, and eager to extend the design principles of the core language into the libraries. (To the point where RFCs for language changes now require a "How do we teach this?" section.)

3. It's got a lot of good, free documentation and (unlike with Swift) there's been a strong interest in providing a first-class developer experience across all-major platforms. (Yes, IDE support and compile times need work, but they're in progress... it's just that they were postponed because 1.0 was all about getting things right that can't be changed later.)

4. The combination of the type system and the compile-time ownership/borrowing handling enables compile-time enforcement of some very appealing design patterns, such as correct use of state machines, locks you can't forget to take/release, etc.

5. I think some of the people in /r/rust/ said it best when they said that Rust should really be marketing its strengths as "fearless concurrency" and "fearless refactoring". Don't underestimate what a load it takes off your mind when the compiler doesn't have to let its guard down because legacy C++ exists.

6. Variables are const by default. Type inference is present without any special keywords, but intentionally stops at "function signatures are your ABI boundaries, so they must be explicit" to prevent inference explosions. Again, giving you the strength of properly-used C++ but with a feel closer to a dynamically-typed language.

7. Like C++, it focuses on zero-cost abstraction. Never underestimate what a mind-blowingly appealing thing this is to people used to coding in languages like Ruby, Python, and JavaScript.

8. A powerful, hygienic macro system which operates on the AST so it can give you more correctness guarantees than C or C++.

9. The community is already building impressively comfortable bindings for extending or embedding runtims CPython, CRuby, Node.js, Lua, etc.

10. It has a trait-based object system that acknowledges that nouns (structs) and verbs (traits) are separate top-level concepts which interact in defined ways, rather than verbs being pieces of nouns (classes).

11. Monadic error handling and greppable panic macros like `unimplemented!` and `unreachable!` like, so it's easy to ensure you haven't left something unhandled. (And there are rumblings about `panic!` itself and how to minimize it even further in situations where you really do want to handle things like malloc failure.)

12. Cargo and Rustup have first-class support for cross-compiling (I targeted my OpenPandora handheld with two simple commands to pull in the cross-tools and two lines in the config file to point it at the GCC I'd unpacked for the final link against the handheld's glibc.) and the community is developing further tools like Xargo to streamline defining and building entirely new targets for things like microcontrollers.

13. Aside from not yet having an equivalent to `#include <foreign_thing.h>`, Rust's FFI story for C already matches C++'s and they have plans to make it better.

14. A runtime about as thin as C's, which you can opt out of even more of... making it especially suited to embedding into things which have their own GC or running on constrained hardware.

...and I'm sure I'm forgetting some of them.

Yes, languages do accumulate cruft, but Rust is such an unusual blend of convenience, performance, safety, and power that it stands out from the crowd and, even when it does get crufty, I don't see myself giving up on it. From my lurking in in the issue trackers, developer discussions, and /r/rust/, it's clear that every design decision has a lot more thought put into it than you'd assume at first glance and I seriously doubt I'll see another language one-up it in its areas of strength any time soon.

Hell, in addition to the "fearless ..." descriptions I've seen before, one of the comments I saw on /r/rust/ that was telling was along the lines of "maybe the mainstream doesn't really need to choke down functional programming's alienness to get the kind of compile-time checking and concurrency-friendliness that everyone is clamouring for. Rust seems to be doing a very impressive job of offering those in a more familiar paradigm."

Now, yes, I will admit that Rust's ownership and borrow checking can be obnoxious at times... but many situations where a valid complaint rather than an eventual egg-on-your-face "Oh, that really wasn't sound after all" moment are areas where, again, they postponed the fix to work on getting as many breaking fixes as possible in before 1.0.

...and, even with that said, I still think it's more desirable than the kind of uncertainty I have to deal with when developing or refactoring codebases in other languages.

Rust is simply a very uncommon blend of good ideas, merged in an uncommonly seamless way.

Edited 2017-01-11 08:06 UTC

Reply Parent Score: 2

Alfman Member since:
2011-01-28

kwan_e,

I didn't say that. As I said before, the point I'm making for this discussion is about the willingness to stick with a language when it does develop cruft. Rust is no exception to cruft.


I don't see why Rust would have more cruft or mistakes than any other language has in the past. Hopefully though we make fewer because we should be learning about programming languages along the way ;)

My feeling about the future is that if people in the next 10/20/30 years want to throw it away and go a new direction, well then let them. They shouldn't be cuffed by our decisions any more than we should be cuffed by the decisions from the 70s/80s/90s...


If you're starting new projects in C++, why would you use the crufty features especially if it costs nothing to exclude them?


By "cruft" I didn't just mean extraneous features, but also features aren't implemented as clearly or strait-forward as they are in other languages. Most of the performance issues stem from normal uses of C++ in large projects.


The difference with languages like Ada (I'm going to stop using C++ as an example since you seem to focus too much on it and not the general point I'm making) is that, yes, it was once a new language. But the community around it continued with it through its own missteps or unwieldiness.


Ada seems better than C++ to me, although I'm much less familiar with it. Is anyone still using it after the Department of Defense dropped the Ada language mandate in the 90s? I think would be cool to discuss it if you submit an article about Ada to osnews ;)


Because you can't build a rustlang economy if there is no momentum behind rustlang.


I think Rustlang in general has a good shot at growing among independent developers like me. But as I indicated in the first post (in the context of operating systems), critical mass may not be possible without larger guys picking it up too. Since I don't have a crystal ball, I'll spare you my speculation ;)

Edited 2017-01-11 09:24 UTC

Reply Parent Score: 2

Rugxulo Member since:
2007-10-09


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 ;)


You briefly mentioned Pascal earlier.

Would you consider Wirth languages as carrying much cruft? Or didn't he throw out enough stuff upon each revision? Were the ISO standards helpful or not for potential users? Would you consider them (or derivatives) worth using today? Or should someone make (yet another) derivative from his work (roughly speaking, the Algol line)?

Reply Parent Score: 1

Alfman Member since:
2011-01-28

Rugxulo,

You briefly mentioned Pascal earlier.

Would you consider Wirth languages as carrying much cruft? Or didn't he throw out enough stuff upon each revision? Were the ISO standards helpful or not for potential users? Would you consider them (or derivatives) worth using today? Or should someone make (yet another) derivative from his work (roughly speaking, the Algol line)?


You know what, I really should know more about Wirth, I don't know much about the progression of the Algol line outside of the two flavors of Pascal I had experience with: Borland Turbo Pascal and Stony Brook Pascal.

SBP was highly optimized.
https://groups.google.com/forum/#!topic/comp.lang.pascal/48biR0sk1_Q

My knowledge of Delphi is patchy at best, so I don't know how badly out of date my first hand knowledge is, but I think many of the features that pascal had in the 90s have aged a bit since then.

At the time I thought it was absolutely great that pascal could automatically catch various kinds of IO/overflow/etc errors. This helped make pascal software more robust (ie compared to C). Overall it seems inferior to try/catch exceptions most languages have now, but considering dominant languages still don't handle numeric overflow, it could still be considered an advantage.

The built in string type was hardcoded as a 256byte array, where the first byte represented length. This allowed some pascal string functions to be somewhat faster than C functions that needed to scan for \0. Also, pascal strings were absolutely safe and this allowed pascal to distance itself from most of C's notorious string vulnerabilities. Something would have to be done to fix the 255 byte string limitation, which was tolerable with 80x25 console apps, but not really acceptable today. Lots of code relied on the length in the first byte and so it has to be rewritten I imagine. And then there's unicode...


While pascal underwent an oop transition, much like C, the resulting duality has always bothered me. While the OOP and non-oop can work together, once we start mixing conventions for error handling and method calling, etc, I find the resulting complexity considerably worse than a language that was always OOP to begin with.

In my experience, C++ code relies more often than not on C libraries and/or syscalls, which we will often wrap up with new OOP classes, logic, exceptions, etc. And although this works as expected, it's a lot more boilerplate work than a language like c# that's always existed in OOP form.


Pascal lacked namespaces, but I think it made up for it with modules and scoping rules, which I find refreshing and I think that's one thing that pascal got very right and many other languages got very wrong. Pascal has child procedures, they're like encapsulation within encapsulation, and I think it's a good idea.

Pascal pointers are not safe like they are in rust or managed languages.

Pascal lacked modern features like closures and generics.

I suspect some of pascal's IO primitives were hard coded into the language, and so it's probably a lot less flexible than stream operations in C++.


Someone with more up to date experience may be able to fill in some of the details. To answer the question: no, I would not use it today as implemented back then. Hypothetically if there were a new derivative that neatly brought it up to date and also offered rust's safety semantics, then absolutely I would be trying it out!


MOTD: Software is getting slower more rapidly than hardware becomes faster. - Wirth's law

Edited 2017-01-12 00:17 UTC

Reply Parent Score: 2