C++ the reason for fast development?

Out of curiosity: The Haiku kernel being developed mostly in C++, is that one of the reasons for the fast development? (OOP but still capable of lowlevel stuff?)

What is fast in an OS that has barely reached beta testing phase in 20 years of development, please?

C++ works for us, it has more features than C which means more tools to solve problems. This makes our code “cleaner” (this is very subjective) and more readable to us (but that could just be because we spent years with this languages and coding style and are used to it).

Other languages might work for other people as well. Including C, I think. It is not hard to write an explanation of why C, a simpler language, is better than C++. Everyone picks the tool they prefer.


Ok, good point. It just seemed faster to me than the GNU/Linux ecosystem which was not built in a day, too. But I think I underestimated the time that Haiku needed.

And you make a good point about how each language fits different coders.

Google Fuchsia kernel (Zircon) and the Genode operating system are also written in C++. Both these operating systems enjoy an equally fast if not faster cadence of development to Haiku.


The advantages of OOP are modularity and reusability. When using a large team, the modularity allows a stubbed interface class to be distributed across a team and all the pieces if code that depend on it can start development while the stub code is still being written as actual methods and data. On a skeleton crew there is minimal benefit to this technique.


I’ve developed software in many languages over 25 years and the longer I develop the more I think the language does not matter that much. In the hands of a capable developer any language can produce good software.

Though I do think newer languages like Rust and Zig can make things a bit easier since they have learned from the mistakes of the past. Also I think static typing provides benefits as well. But overall I think the most important thing is competent developers putting in a lot of time.


Bummer, I’m disqualified already :smiley:


You become competent by making all the mistakes and (hopefully) learning from them. I’ve certainly made plenty in my time. Though I know you are mostly joking. But I think many people need more encouragement to not be afraid to make mistakes and learn from them.


Agree 100%. And even if some of us have seemingly reached our programming ceiling, we still are able to contribute here and there (given enough time/dedication/luck).

Heck… I always say to people on IRC: “If even I managed to squish some patches in to both Haiku and Haikuports… anyone can do it!”.


I had some similar thoughts :upside_down_face: not to mention that I’m not putting in so much time.

At least one thing could be said on the positive side: I’m not afraid to make mistakes :rofl:


Thanks for your insight. I like the safe code of Rust and the lower-grade, opt-in version in D but sometimes I wonder if shortcuts to the same results creates as many problems as they solve.

C++ started out as CFront, a transpiler for OOP in C. People still need to know most of the low-level concepts of C to debug some of their code.

I think that having well debugged and optimized high-level constructs help build software quickly at a cost of having the design patterns of one generation define the syntax shortcuts of the next. Moving from BASIC to Pascal and C was the patterns of structured programming. Moving from Pascal to Object Pascal and C to C++ was the object-oriented programming iteration.

In the next generation, antipattens were noticed in the previous generation such that conventional forms of inheritance causes excessive amounts of dynamic dispatch such as methods being preferred over static functions. That’s why Rust replaced both conventional inheritance and interface inheritance with a more optimizable trait inheritance mechanism. Also, thread-safety became a bigger priority as well.

The Points I’m Trying To Make

Too much abstraction between a language’s implementation and its syntax makes for too much complexity if it goes in one jump. I favor transpiling over super-high-level languages so you can judge each stage of compilation. The higher level the language, the harder it is to fully debug the compiler.

That’s true, but one advantage of C++ (not exclusive, some other languages do allow this too) in the context of Haiku (a complete operating system ranging from kernel to userspace) is it’s ability to handle a wide range of problems and environments. The downside of this is, it is a very large language with lots of things to explore.

In our case I think this makes it a good choice of languages, but in other situations where the scope is not as wide, it may be a good idea to pick a language more specifically tailored to the needs?