Agreeing with all of this; although perhaps to make the transition easier between the current codebase and whatever a rewritten Haiku will be, Swift might be a good candidate to consider in the future due to its C++ interop. That would prolly require that Swift itself be working in Haiku first, however.
1 Like
Swift is already available, please see here:
The C++ interop is still a bit immature as of now.
Itās not exactly held in high regardā¦
With the US Govt now putting pressure on the Tech industry to use safer programming languages, some C/C++ enthusiasts might do a safety upgrade of those 2 languages, and create a way to introduce the new coding into existing projects.
Meanwhile, newer languages seem to have better features, more efficiency, and a less steep learning curve. The next decade could be interesting for programming languages.
2 Likes
The only way you can make C or C++ safe is by removing a lot of the basic features (like pointers). As long as you allow free pointers (not managed by a shared_ptr or similar) in a codebase, your code is not safe.
So, you can put the āCā or āC++ā tag on a new language, but regardless, it will be a new language. In fact, it would probably look more like Java, or C#, if you do just the basic things.
It seems the C++ committee has started work on āprofilesā, that means, you could, in theory, enable āsafe modeā and have everything be checked.
Iām not entirely convinced by the āease of learningā argument. For C++, yes, you can spend a lifetime learning about all its little-used and legacy features, but do you really need to? On the rust side, you have to learn quite a lot about the memory model, borrowing references and the like, and I didnāt find the syntax particularly easier (maybe I just spent too much time with C++ and now I canāt do anything else). In any case, I have not seen any backing for the āitās hard to learn C++ā claims, and Iāve seen Haiku users who never did any programming learn it and write some nice apps. So Iām curious and I may leanr something: where do the claims that C++ is hard to learn come from? What were they comparing it against? Have someone done similar studies on Rust or Swift or other languages?
1 Like
Good question. I found this on Google Scholar. It may interest people: https://tinyurl.com/2b8a5s86
Yes, thatās pretty much why I prefer yab.
I can read and write C/C++ (but not newer language feature), Swift and some Rust. I am just hacking C++/Rust mixing project now, I am relatively happy coding with Swift at work.
In my point of view, C++ is hard. It is too powerful and too expressive to allow many programming paradigms. Imperative, OOP, functional constexpr template meta progrgmming, blackmagic with macros.
I can select modern, sane, strict set of language feature to use and can enjoy programming in consistent code style, but when I import otheroneās existing code vault in the project, it immediately became complex one.
C++'s policy keeping compatibility is great, but newer languages avoid some language feature to prevent automatic code refactoring or analysis and incremental code migration to newer edition of the language.
This is good news and evolution on tooling may change the current C++ reputation.
1 Like
Generally, newer languages make improvements to overcome problems with older languages, and, so, they tend to be easier to grasp. e.g., the V creator says his language can be learned in a weekend.
The exception is Rust, which, being a systems language, is said to still have some difficult areas to deal with.
But, as you say, they all need some devotion to be able to use them.
1 Like
That assumes there is a āperfectā language and that each iteration is a step towards it.
I think things are more complicated: each language either:
- Solves a specific set of problems, but as a compromises, make some other things more difficult,
- Tries to solve everything, but as a result, is extremely complex and has dozen of solutions to each problem, with sometimes none of them being satisfactory.
So, the question is not wether a language is better than another in general. You can only answer āwhich is betterā in the context of a specific project. If you have already written code for 20 years as is the case in Haiku, and have assembled a lot of collective experience in a language, that gives a lot of points for staying with that language. So, to justify a switch to another language, even the advantages of Rust could be questionable. They are there, but do they overweight the 20 years of code, the difficulties of keeping two languages side by side for the next few years (which means probably adding up the disadvantages of each language), and so on? Maybe not so.
If youāre starting a new project? Or if youāre planning to rewrite your entire codebase anyway? Yes, definitely consider Rust. But here, itās not as easy to decide.
4 Likes
If we started over today, we would probably not use C++. But if Haiku did not already exist we would not be setting out to rewrite BeOS from scratch either 
. The āwhole stackā is contemporary to its era.
As a Genode fan I feel a little wistful that they have state of the art architecture but committed to C++ really only a short time before Rust was a thing. However I am given to believe their C++ is a more modern dialect than BeOS used.
So is ours. The Haiku kernel isnāt bound to āBeOS C++ā and does use newer features where it makes sense. Even in userspace code built with GCC2, we have classes and templates that BeOS did not.
1 Like
I think the more classic C++ API is a feature, for some of us. Thereās less going on, so if you arenāt heavily into C++, itās easier to brush up on the aspects you need to know to to get a some BViews working. Definitely for me, the classic API is the part that can be adapted to other languages.
I may have to take back some of my negative comments about Rust. Iām getting back into it, and this time itās going a lot more smoothly. I mean, all that borrow checker stuff is still a hassle, but so far I havenāt had to do any lifetime annotations at all, so either Iām getting off to a better second start, or the compiler has gotten smarter in the intervening years. (It has, just not sure about the timeline.)
And in the process Iām hearing a lot of stuff about Rust having been adopted in a lot of shops. Like weāre already seeing it show up in applications that are being ported to Haiku, and itās likely that libraries and such will start becoming available that are written in Rust. Thatās what in my opinion will sensibly drive Rust into a supported second language position on Haiku, meaning adequate access to the API. You can write the GUI for a Rust library in C++ (Iām guessing), so it isnāt critical, but there will be a constituency for this.
I still believe that D is the only straightforward answer to a language that directly integrates with an existing C++ codebase. D and C++ can call each other and link inside the same project, which allows a gradual move from one language to the other. There are some issues to work around but itās still more directly compatible with C++ than any other language. It has strong memory and type safety, and numerous higher level language features. Carbon appears to be an interesting alternative but is still in its infancy.
3 Likes
Something to look out for in D, if anyoneās seriously exploring it for use with the API, is the garbage collector vs. API interface kit threads. D appears to have some support for registering an externally created thread, so this is probably a topic that has come up there and could be easily looked into.
The issue is that a garbage collector may mean a non-re-entrant runtime, where external non-D functions that access D data have to lock out other threads. This kind of spoils the concurrent user interface. If one window in your application gets hung up on some network access or whatever, the rest wonāt be able to redraw or anything.
1 Like
This makes sense. I would expect D to have some facility for passing a bit of per thread state around to solve this, which would have to be integrated to/customised for the OS. But I donāt know the detailsā¦
Is D available on Haiku?
Nope, I managed to build some basic package a while ago with gcc11, after that gcc needed patching to bootstrap it (IIRC, itās been a while). 
EDIT, found that gcc_gdc package again
But no where near to be useful from my conversation over Tokodon back then.
References:
https://briancallahan.net/blog/20230626.html
Maybe someone with some more knowledge can chime in
EDIT2: a bit of background on this
1 Like
I have played with bootstrapping D for arm-none-eabi on gcc14, I think it gets easier with gcc 14 because gdc and photon are built in to the gcc package.
1 Like
Now if I could run on bare metal again I would love to give that a spin.
Mojo is another language with great potential:
Wikipedia: āMojo is a programming language in the Python family that is currently under development. It is available both in browsers via Jupyter notebooks, and locally on Linux and macOS. Mojo aims to combine the usability of a high-level programming language, specifically Python, with the performance of a system programming language such as C++, Rust, and Zig. As of 2024, the Mojo compiler is opensource software (closed source) with an open source standard library. Modular, the company behind Mojo, has stated an intent to eventually open source the Mojo language, as it matures.ā
1 Like