“Vale aims to … offer speed, safety, and ease of use.” Sounds like a good language, but after 11 years is only at V0.2.
There’s another one in the same vein, called Lobster. The Vale & Lobster devs compare notes. The Lobster guy explains his language very well, which is rare.
https://strlen.com/lobster/
http://aardappel.github.io/lobster/README_FIRST.html
Dr. Wouter van Oortmersen is the author of Lobster. He was also the original author of AmigaE which I maintain a port of for AmigaOS 3, AmigaOS 4.1 and MorphOS.
Hilarious!!! 
I also love Rust language, but as far as I know rewriting something in Firefox was not just for the old code is unmanageable.
They rewrite some of their components for performance and security reason.
They started Servo project to experiment utilizing parallelism in layout and rendering the Web.
Firefox got the rust-written Stylo (CSS style computation module) which improves maintainability as a result indeed, but was not main goal. They also got GPU-offloaded rendering and composing engine, WebRender. This modernized their rendering pipeline.
They stopped investment to the Servo project. This was not because Servo failed whole rewrite in Rust which is non-goal, but they couldn’t continue as financial situation was changed.
Anyway they got non-trivial fruits from their experimental project so it was a (somewhat) success.
Rust supports avoiding some pitholes when building highly parallel programs with least overhead, so it made sense for Mozilla as Mozilla is building cross platform programs which is hard to consult platforms’ high-level mechanisms which support asynchronous parallel program.
Haiku has designed with multicore computing in mind since day one. So rewriting in rust is not needed if it isn’r broken.
(EDIT: some my poor English…)
At the end of Mozilla’s role in the Servo project, they tempered their expectations due to the financial burden. They are still rewriting sections and dependencies of Firefox in Rust to improve maintainability and parallelism.
The Expat library was one of their next targets to experiment with after they merged WebRender and Stylo. Spidermonkey (or whatever the JavaScript and WebAssembly JIT is called) didn’t need replacement because the C++ version was already well debugged and not modular enough to warrant replacement with Rust.
One last thing to note is that Stylo was previously attempted multiple times in C++ and failed before Rust was developed to try again. The Rust version succeeded where the C++ versions didn’t.
Like the JavaScript JIT, Haiku’s kernel has 20+ years of development and doesn’t need replacing yet. The Windows kernel is being replaced by Rust code after 30+ years of development in C and C++ so maybe in 10 years we can revisit the matter or even migrate to a new kernel or operating system as a whole. That’s up to the end-users to decide.
If the @safe directive in D is as good as it seems, that looks to be a more cost-effective rewriting tool than Rust.
Migrating to a new operating system completely, such as the TheseusOS with its exokernel written in Rust, may have come some distance in 10 years, making it more attractive to safe-code users and developers. Its cell-style diversion and deprecation mechanism may dwarf the flexibility and modularity of C++ based ecosystems but it’s not there yet.
I’m fairly sure the decision of what language to develop the system with is on the developers who write the code, not the end-users.
As I said, the main reason to keep doing C++ is because everyone writing code in Haiku knows C++. It is difficult to find another language that everyone in the developer team is happy with. So that means you have to make a choice between two options:
The first options is “business as usual” and doesn’t need extra commenting. Let’s look at what the second one would do.
First of all, some developers may just leave. So that’s lost knowledge.
Second, the code must be rewritten, which means inevitable subtle changes in behavior, especially because our unit tests are in extremely bad shape and so they are useless. And at this point you want to turn to the old developers to see if they remember what they did in the old code. But they left the project, so you don’t know.
And then, there are the people who remain in the project but don’t know the new language. This means now there are some parts of the project that are rewritten in a language they don’t know. At best they can read the code to understand what it does. But, they are not able to do code reviews for it, and even less able to contribute patches to it except for the most trivial changes. So, we loose one of the key “selling” points of Haiku: we believe that having the whole OS developerd by a single team, where everyone can seamlessly jump from GUI to kernel development, allows us to provide a tightly integrated and consistent OS. This will not be the case anymore.
As long as there isn’t a complete rewrite, there are areas of friction. Let’s say for example that the kernel is rewritten in Rust (I’m using Rust as an example here but you can replace with any other language you want to see used) but userland stays in C++. And let’s say we want to be more “microkernel” and move some code from kernel to userspace. What do we do, do we rewrite the Rust code in C++ when moving it? Do we allow Rust and C++ to coexist in both the kernel and userspace? How does that even look like, given that the Be API is heavily tied to C++? A mixed languages setup forces us to completely redesign an API that works on the “smallest common denominator” of the two languages, making it a nightmare for both Rust and C++ developers. Or, if we don’t do that, to design two independant APIs, and again, the “system consistency because a single team is in charge of everything” goes down the drain.
That’s the main problem here. You can discuss the merits of various languages as much as you want, of course, obviously, there are many modern languages that may be a better fit if you are writing an operating system from scratch. But we are too far deep in our own little C++ hole now. I think that’s OK, maybe you don’t agree, but in any case: this is a human problem and not really a technical one. Would a new programming language work, if analyzed “in a vacuum”? Yes, probably. Would the existing developers instantly switch to it? Probably not, for many reasons.
I hope to see Redox OS (for the Rust supporters) get as much success as we do. And I hope to see the other languages get their own OS as well (some may already exist, I don’t have an eye on everything). And if one such language allows to do things 10x easier or 10x faster than C++, surely that project will catch up and do better than Haiku. Maybe some of the team members will “jump ships” and start contributing there and using that better OS.
Or, if you somehow think starting from Haiku and gradually rewriting it in another language is the better way forward, sure, start hacking on that! Let us know how far you get, it’s exciting to see Haiku codebase used in ways we didn’t expect it would be!
Not at the moment!
Still a lot things to do and to implement!
Ship jumping is the part that the end-users will decide. Will they decide to rewrite anything? No. Will they decide what language the new operating system they jump to is written in? No. Will they decide what features are used be the new operating system? A thousand times: NO!!!
TheseusOS is not Posix and may take more time to adopt due to its dependence on safe languages starting with Rust. RedoxOS is a Posix operating system written in Rust but as a Posix OS, it must support code written in C. Haiku is a Posix operating system according to an early specification. It has a lot of ports as a result of that. Regardless of whether people think that native apps make the OS, sometimes the old standby apps ported from Linux make a bigger difference on a Posix OS. It makes the ship-jump easier.
There is only one distribution using the NewOS kernel variant called Haiku. This is a licensing decision made years ago and will help with the directing of users to a single entity that doesn’t fork often. If it does, new name, new OS designation for the fork. Haiku is Haiku and there is no changing that.
Since there is no forking to be observed with the Haiku designation, I’m anticipating the ship-jumping mentioned earlier will be to another OS. Otherwise there won’t be any reason to leave. I’ll put my money on the techniques of TheseusOS, if not the kernel, being a game changer. Its main feature is that an exokernel using safe langauges for all of its native code will not need overhead associated with memory-protection.
Theseus’ kernel is used for embedded work so far. They’ve chosen not to bite off more than they can chew so the development need not be monolithic. I’m betting that the lack of distinction between user-mode and supervisor-mode will pay off once the library-writing sets full sails. Their cellular modularity will make distributions and operating systems based on the lack of centralization.
What is the cellular modularity of TheseusOS? The idea is that as new libraries with redundant functionality naturally occur by the attempts of others to reinvent the wheel (as is the topic of discussion here). The difference is that the migration path to the new library is for the old one to call the new library’s functions and be stubbed out until the libraries and executables of TheseusOS (called cells in their lingo) will be redirected to the new library and the stubbed out shell of an old library will die. The goal is such that new concepts can be introduced without downtime.
On Haiku, every executable and library is a PIC shared object of sorts. (At least I think so.) This will allow the cellular life cycle of libraries to be modular in the same way. Say, for example, that MediaKit will be phased out in favor of a new one called StreamKit. This means that all of the functions of MediaKit can call the equivalent functions of StreamKit. Once the functionality of MediaKit has been completely redirected to StreamKit, can you ever truly get rid of MediaKit? Not on Haiku’s current setup. Closed-source software is distributed as binaries rather than bytecode. This makes them impossible to fully patch to allow the full elimination of an obsolete system library. Deprecation becomes the end of the life cycle but the shell of the former existence will always remain.
Going back to the ship-jumping idea, I don’t think we’re at the point where ship-jumping makes sense. Haiku is financially beholden to Google for their Summer of Code policies so if the politics of the industry goes bad, ship jumping may become necessary.
After looking at the Theseus Book web presence, I see they are experimenting with an unprotected C runtime. (If that was what I wanted, I’d still be using MorphOS. Oh wait! I still DO use MorphOS! ) Jumping ship isn’t always permanent. Maybe C++29 will be vastly different from existing C++20 and have safety features like D or Rust. Maybe the monolithic operating system approach can be revisited then. Until then, I am choosing to learn to use the features of safe languages in the applications I design.
I’m sorry but this makes no sense. Bytecode is just binaries compiled for a CPU that does not have an hardware implementation. It is not harder or easier to patch than any other type of binaries.
What? The Google donations for GSoC (I will emphasize donations, there is no counterpart) are 10% of our yearly budget or less ($2000 of a total of $23000 in 2022: https://www.haiku-inc.org/docs/haiku_inc-financial-report-2022.pdf). If they go away, well, we will have a little less money. That does not put the project at a big risk, maybe we will have to cut down on our single paid developer. But then again, we have $105000 of assets, so even if everyone stopped donating all at once, we would still be able to pay the one paid developer for at least a couple years, possibly more, before running out of funds. And if just Google stopped giving us money, well, we would remind people that we need more funds to keep the project ustainable.
Also, if GSoC stops, we will not spend time mentoring students over the summer, which means we have more time to write the OS and fix bugs instead. I think this would greatly outbalance the $2000 that Google gives us.
Haiku is 20+ years old at this point and it went from “why don’t you use Zeta?” to “wgy don’t you use Linux?” to “why don’t you use BSD?” to “why don’t you use Fuchsia?” and now it’s “why don’t you use TheseusOS?”. I think people are running out of things to suggest, because, as you said, this is an OS that doesn’t even target desktop systems. So, we can live side by side and everyone will be happy?
As for people “jumping ships” (to an OS called TheseusOS, that’s kind of fun at least 
), I am not really worried. Because I don’t care if we have many users. What I need is an OS that works for myself. For the last 15 years, Haiku has definitely provided that, and I don’t see why that would change, since I’m able to fix most of the problems I get with it. Having other people fix it instead of having to do it myself surely helps and allows me to do a few other things with my life, sure. But also, I don’t see TheseusOS as a thing people would jump to, since it is not a desktop OS. So I don’t understand what you’re saying.
End users in general don’t decide which OS to use based on the operating system used to write the kernel, unless they have some specific requirements or interests.
In general a programming language is a tool to develop software. As with every tool some languages fit better to certain types of software then others. As a user of any piece of software this most of the time is of little concern to me, as I’m interested in what the software provides to me, not what the tools used to create that software provides for the developers.
As a developer it is of course important which tools are being used. But in this case it’s also the developers, those who actively contribute to a project, who need to decide on the tools. I have seldom seen switching languages of an established project to be beneficial, unless there was a fundamental problem with the code (and it needed to be rewritten anyway). In this case I find the entire discussion for Haiku a bit odd, as there seems to be no specifc issue with Haiku’s code base currently has that needs addressing.
As with most of these purely superficial discussions here on the forum, I simply don’t get it. What’s the benefit of discussing programming languages nobody is submitting code for and in anyway (EDIT: I mean on Haiku, not in a general sense).
Now, if somebody manages to write a new component for Haiku in let’s say, Rust, and asks for it to be included with the OS, that will be the point of discussing if and how non C++ code should be included.
As long as everybody that actually contributes code to the OS is happy with C++, why should anything change?
I’m glad to hear that Google’s contributions are not a significant loss if they decide to pull on the leash. In the case of Mozilla, Google’s contributions are more like 80% of their budget so the real independence of the Firefox browser vs. the Chrome browser is suspect. Apple’s contributions to the WebKit browser engine also make that framework tied to the current market leaders, though thankfully independent of Google.
I’m wary of the market leaders trying to sink financial tentacles into independent projects like Haiku to exert control over them.
@PulkoMandy I haven’t thanked you enough for the work you’ve put into Haiku and Haiku’s implementation of WebKit. I was surprised to see a headline in my newspaper begging iOS users to update their phones because of 3 zero-day exploits all in WebKit recently. For a massive codebase like that of a web browser or supervisor mode driver collection, I’m continually suspicious of how easily some sort of malwre could be introduced and the end-users would be none-the-wiser.
Saying that wheels don’t need reinventing is just as valid of a response to this topic as saying that some do. Thanks for your on-topic input!
Remember, MS is not rewriting the entire NT kernel in Rust - just parts involving known security risks.
As for Haiku, start with the 30+ year body of C++ programming knowledge (aka dev trials, errors, and trickery) going back since the BeOS era.
Then. remember binding native and third-party code to the new Haiku kernel model. Retesting that code for the same test behavior and passibility.
Then, software maintainability and buy-in from the existing C++ dev team (and sponsors). This
includes retraining efforts and rewriting or updating all training periodicals for current and new recruits.
Possible? Yes. Affordable risk? Well…
But, lessons learned come from other project’s like Amiga when they converted code from BCPL/assembler - or certain design strategies they did. One devs hand things off, other contributors must understand and retain capability to support it for awhile or the ball eventually gets dropped by general code inexperience or redundancy within code reuse.
Just thoughts…
Please note that this is only part of what I said. I certainly don’t want to come across as being against progress or change. But both progress and change in a non-commercial open source project (as we all know) only occurs if someone is willing to do the work, not by simply writing about it.
This is a smart decision. Haiku could probably use D programming language for that purpose. D goes well with Cpp. After all, the D language was created as an improvement of the Cpp language.
Strategically, one could plan, say, to transfer gradually the Haiku programming code to the D language in 50 years.
So, if anyone can and wants to do this, go ahead.
There are a number of reasons I look for novel projects to work on. Usually potential impact to “upset the apple cart” within the computer industry is a main reason.
I’m not professionally employed but suspect the global economy will be scuttled by unsavory influencers in an attempt to force central banks to adopt digital-only currencies. Without getting into politics any farther I’ll just suffice to say that if fiat currencies are going to collapse, I need not focus on earning money.
In order to be sufficiently stocked with disriptive technologies, I need to know the most novel motivations to develop charitable nonprofits’ software. I’m in it for sport rather than profit. The most disruptive technologies that motivate me are ones that cut into the profit margins of market leaders.
Google’s main operating systems are Android and Fuchsia. Microsoft Windows is still a contender. MacOS and iOS are Apple’s babies. The Amazon Kindle Fire and its offshoots run a fork of Android also. Linux software is open source and often Posix influenced making it an easy port to other desktop operating systems that implement Posix standards. Posix ports make a good start but don’t win the competition.
The most unique and novel features of Haiku include stack and tile user-interfaces that improve integration with separate programs that work as one, a queryable filesystem with user defined metadata that makes simple databases functions of the filesystem and ultimately, a multimedia processing framework that potentally could upend other mainstream editors once MediaKit is sufficiently debugged.
Haiku is a good operating system. It’s not jaw-dropping but it shouldn’t really be jaw-dropping on its own anyway. Applications that take advantage of the plumbing that supplies capabilities to them should be the jaw-dropping part.
What is needed to get me involved is an application idea that has the potential to make Haiku a shining example of what an operating system should be in the current age. Retrocomputing platforms like the Commodore Amiga series and BeBox set the stage for the final act of the play. So who will write the game changing script? That’s why I started this thread.
Bytecodes like WebAssembly can do a little but are developing slowly. What I value in them is the ability to level playing fields in the compatibility space.
Safe languages are a tradeoff between learning them as a cost and reduced debugging time as a dividend payout from the time investment.
The fact that Haiku doesn’t have an exokernel like Theseus and uses old-style memory protection instead of shifting safety to compile-time looks to be something of a mixed blessing: Posix compliance is achievable enough to bring in a lot of ports but the downside is they are necessary, quite often because few people have the willingness to learn a new operating system at all, let alone take full advantage of its novelty.
@BlueSky The reason I didn’t fully address your post is I had to run to spend time with my family and friends on the holiday of Memorial Day; a holiday to commemorate war dead and other veterans that have passed away here in the United States.
It might be worth looking at how Serenity OS is progressing with their own language Jakt. Of particular interest is that Jakt is intended to “transpile” into C++ code of their existing codebase.
This seems like a promising approach but maybe it is too early to draw any conclusions. Nonetheless, and despite it being a project instigated by a rival OS there is nothing stopping us from contributing to its development if we thought it might be of use to Haiku.
This is not completely unique: Nim (as one example) already compiles into C++ code.
But why would we? So far all this thread has been people saying “my preferred language is better than C++” without any arguments or explanation about what kind of bugs it would fix. And indeed, as a result of this discussion, the total number of bugs fixed is 0.
As I and other people have said multiple times, if someone wants this to happen (and it will probably not be one of the existing devs who have been doing C++ for decades), they have to show serious proof that:
If just one of them is not true, well, we’ll keep C++ because that works for us.
So, really, if you want an OS written in another language so hard, it is actually easier to start you own project. Why would you put so much effort in hijacking Haiku, an existing project that runs perfectly well and is finally getting somewhat close to release, and ask the existing developers there to spend the next decade rewriting all the codebase in a different language instead of finishing the OS?
I thought nim compiled to C?