Just wondering, assuming that Swift can be fully ported to Haiku how feasible would it be from a language featureset perspective to allow new code in Haiku to be written with it? To be clear, this is not about rewriting Haiku in Swift or whatnot. But just for new contributions and not for all of them, at least initially.
Even if it were possible I don’t see Haiku being fully rewritten in Swift, even after a long time. Maybe the parts that are more sensitive to memory leaks and security issues, but that’s it.
The main limitation currently is that there is no support for virtual methods. That makes it quite difficult to use for anything using Haiku APIs, especially for the GUI, since that is entirely based on subclassing. But it should still be possible.
I don’t think mixing two languages in the same project is a great idea anyways. You end up with something that is even more confusing than each language taken separately. Which is why I said I would consider Swift if I were to start a new project. Obviously that is not Haiku’s case. It would also have to be discussed with the other developers. In fact, the challenges are more likely social than technical. When Haiku decided to start using C++ in the kernel, some developers who were working in C there previously, have stopped contributing. Surely the same thing would happen with a Swift (or Rust or whatever else) migration.
This inter-operability, however, is great if you have an existing C++ codebase and want to migrate it to another language. Instead of throwing away all your code and starting from scratch, you can do that rewrite one part at a time. Ladybird is exactly in that situation, let’s see how it goes for them.
On Haiku side, before we start considering if we should start such a migration, maybe let’s get a compiler running (again) and port an app or two first? Also, is Swift even usable for kernel-side code? Is there a tradeoff between the safety and the performance? I don’t actually have a lot of experience with the language (I read half a book about an outdated version, and some tutorials by the language designers, and that’s about it), so I have no idea about these things, which should be considered before any decision would be made.
Of course, yes! I was asking from a more theoretical point-of-view (presuming that Swift already works on Haiku).
This is a bit outside from the scope of what I had asked, but true! Linux for example had to overcome a lot of resistance among its developers, before Rust code was allowed in (besides technical needs). It would prolly happen with Haiku and Swift, too.
As for Swift for Haiku, I would not expect a full migration of another language (Swift, Rust) being introduced to replace another (C/C++) in the kernel or in the whole OS. Even if that was to be considered, it would ultimately be up to the core Haiku developers to decide on this.
But I personally would not want to mix two or more languages directly in Haiku’s kernel since it just creates more complexity and context switching into the project and I’d rather just keep it as an external third-party supported language in HaikuPorts.
Overall, I think Swift will benefit from the direct C++ interoperability feature to be used from existing C++ libraries and up to large-scale software such as browsers like Ladybird and already in Arc Browser (which uses Chromium as its core which is in C++).
But we’ll see how it goes over time, but any decision on any new language integration into Haiku has to go through the core team members.
BeOS was a clean-sheet response to the need to move on from legacy stuff and in the 1990s C++ itself would have been pretty new. In accordance with this philosophy I would prefer that any such effort needed to rewrite everything again were applied to a whole new OS to utilise todays legacy-free language. Only if your codebase is tiny to start with - and I would love to hear more from HarveyOS’ r9 rewrite of Plan 9 in rust - does that approach seems to make sense. So stick with C++.
I am already in agreement with keeping Haiku’s kernel the way it is (in C++) and not introducing another language to migrate to.
But I personally would not want to mix two or more languages directly in Haiku’s kernel since it just create more complexity and context switching into the project and I’d rather just keep it as an external third-party supported language in HaikuPorts.
Again, any language (even using a new C++ version) in the kernel and OS would be up to the core team to discuss this.
I should indeed have made it more clear I was agreeing with you. I regard BeOS as largely a creature of the C++ object oriented paradigm that was in the ascendant at the time and a new programming language should be free to inspire its own operating system concepts.
Whilst already outside the scope of this thread, I don’t see why newer versions of C++ would in any way be controversial. C++ is a living language, and Haiku is a living operating system, and it seems natural they would evolve together.
That culture actually goes further back, at least to Smalltalk on the Xerox Alto. Not only is it an object oriented language, it’s also where the window tab design comes from.
So, from the object oriented point of view, maybe BeOS is a step back compared to that, mixing object oriented and procedural elements, and, in a way, bridging the gap between Smalltalk and UNIX.
Anyway, besides that, yes, the API design is very much entangled with C++, and, if you wanted to make the most use of Swift, it would make sense to start from scratch, even if you take a lot of inspiration from BeOS or Haiku (as they did take inspiration from their predecessors).
I’m not sure what we’re really talking about at this point, but … it’s an opportunity to point out one of costs of a “living language” that’s sort of vaguely relevant here.
If you want to use other languages on a platform whose API makes integral use of C++, you have some adaptation to do. Whether the language has something congruent to those C++ hook functions or not, you’re going to end up with a lot of scaffolding.
Be’s use of C++ was pretty conservative, by modern standards, and it’s fairly simple to figure out what you need in that scaffolding to give your alternative language access to that foreign API. As the API starts to have more modern features, it’s obviously harder. How much harder, depends on the feature. Templates for example, could be next to impossible to incorporate in any meaningful way - I don’t know for a fact, maybe just haven’t given it enough thought, but I think so. So API elements that use them are more definitively C+±only. If you care about other languages’ access to the API. Swift, Rust, good old not-so-trendy Ocaml, etc.
The only good language is a dead language. Seriously. If they need to mutate all the time, evidently they weren’t very well thought out to start with.
It’s not that controversial. But most “modern” things are somewhat held back by the parts having to be compiled by gcc2. However there are ideas to implement some newer C++ features into haiku. But this is an experimentation, and we can then decide if it makes sense to do so or not to do so. It’s not a given that we will adopt all new language features. : D
Swift would also make sense from a the ability to extend features of the platform. Since there is many pitfalls of dynamic linking in c++ since the ABI is fragile. This is something that is done right in Objective-C and swift and that is without requiring setter/getter methods for anything that might be accessed from the outside of a dynamically linked library.
Bad devs are bad at any language, rust, swift, GO, etc., these languages hide incompetence and lack of skills. Good security practices and care in writing code to manage memory are necessary skills.
That’s not the question. Bad devs will be bad, but if you have a bad language, good devs will also be bad and make stupid mistakes. Ask me how I know
If you have a tool that solves this, why would you not use it?
In the case of Haiku, migrating to a different language may be difficult, but if you’re writing a new project, definitely have a look at one or more of these new languages to see if they could be a better fit. Then you don’t have to waste time on stupid mistakes again, because they are simply impossible to make in that language (you probably get a different set of stupid mistakes, hopefully ones that are harder to make and there will be less of them).
One skill a software developer should have is being able to reason about code and being able to use tools that allow to express and verify that reasoning.
Unfortunately, a common trope in programming culture, especially low-level programming, is to cover the lack of this skill by claiming that people who have this skill are incompetent. This is what you usually see in C vs Rust discussion: a tool that verifies a very limited statements about aliasing and lifetimes (borrow checking) is confused for a some kind of training wheels (supposedly preventing programs to fall apart due to incompetence of a programmer).
This is why such discussions are rarely interesting.
