If your language allows seamless interop with C++ then sure, go for it. But what if it doesn’t? If I or someone else port Kotlin Native what would be my option to use it for Haiku development? It has a comprehensive C interop, but offers nothing for C++ (JetBrains tried to create C++ interop but quickly understood the amount of work that needed to be done, and switched their focus to more strategic things). Hence I would need to use either the C bindings or the Objective-C++ bindings. There’s no tool that can generate the latter, if SWIG or some other tool will be able to do it one day, it would be the obvious choice for Kotlin Native developer, until then there’s just plain old C. It’s not perfect but it works with every language out there.
No language I know has seamless interop with C++. Reportedly it’s close with Swift, but that’s kind of the point: to do this in some standard way, the ‘target’ language has to be fundamentally similar to C++. Ocaml and Rust aren’t, so the solution for one is fundamentally different from the solution for the other. They can’t both get what they need, from the same C wrappers.
If Kotlin has big an industry footprint as it looks from reading the wikipedia page, and a C++ foreign function interface was abandoned as too difficult, I’d have to guess that it’s very much the same situation.
One of the advantages you have when you’re addressing the problem with some lame home-rolled interface wrappers, is that you don’t have to solve problems that we don’t have on Haiku. Or don’t have much of - the Layout API is a special case, but most of the API doesn’t use templates and is seriously basic C++.
From what I heard, the best C++ interop is provided by Carbon and D, but I never used them.
Just to be precise, I was writing about Kotlin Native, and not regular Kotlin 
Same authors, same syntax and similar name but different industry footprints and different targets (native executables vs JVM bytecode). I’d say JetBrains has abandoned the idea since it’s not their main focus for native platforms (iOS is, and KN has Objective-C interop), and because they didn’t have enough resources to work on something complex to implement that wouldn’t help their business in any way. Now Apple (who has infinite amount of money and resources) tries to implement it in Swift, it looks promising but many things are still unsupported. Let’s see how far they can go.
Donn:
“No language I know has seamless interop with C++”
VoloDroid:
“From what I heard, the best C++ interop is provided by Carbon and D…”
Nim is supposed to be interoperable with C/C++. It has already been ported. It’s Python-like in syntax.
Wikipedia:
“The Nim compiler emits fast, optimized C code by default. It defers compiling-to-object code to an external C compiler to leverage existing compiler optimization and portability. Many C compilers are supported, including Clang, Microsoft Visual C++ (MSVC), MinGW, and GNU Compiler Collection (GCC). The Nim compiler can also emit C++, Objective-C, and JavaScript code to allow easy interfacing with application programming interfaces (APIs) written in those languages; developers can simply write in Nim, then compile to any supported language. This also allows writing applications for iOS and Android. There is also an unofficial LLVM backend, allowing use of the Nim compiler in a stand-alone way.”
I managed a little test program, Nim invoking a class instance method in a C++ .o with no extra interface, picking up #define values. I kind of got feature indigestion from the smörgåsbord of features in the manual, but there’s no question in my mind it could be hooked up to the Haiku API pretty well one way or another, maybe even Layout.
It even supports “var” (write) parameters, like C++, but of course you’d still have to know which parameters in the API are of that type, and you’d have to know who’s keeping pointers to BMessage et al., and deal with that appropriately if you’re using the reference counting model.
I didn’t find anything about how you’d set up a thread that originates from BWindow for example No doubt there’s a way, but it may not be documented.
You could write a program in Nim. You may have to wrap some of the Be/Haiku libraries, however.
You bet, likely a subclassing wrapper for each class where you want to use its “hook” virtual functions, which would be essential with the interface kit.
Ballerina is also a C-style (new) language that has some interesting features - best of which for Haiku are the multithreading and API focus. And it alo has a useful diagramming ability.
- Open source, cloud-native optimized for integration
- Rich ecosystem of network protocols, data formats, and connectors
- Edit/view source code textually or graphically as sequence diagrams and flowcharts
- Built-in, easy and efficient concurrency with sequence diagrams and safety primitives
- Built around supporting application programming interfaces (APIs) as a first-class entity
This is known as a “graphics driver”. I come from the world of microcontrollers and embedded devices; the name of the software components is different, but the operation is the same.
Re:Ballerina
You forgot one of the most important links: the installation instructions for installing from the Zip file. I’m trying it now. It seems to only depend on the OpenJRE version 17. We’ll see how it goes.
UPDATE:
Installing OpenJRE17_Default from HaikuPorts and adding Ballerina to the path of the current shell works. I tried running bal update and it failed but the bal --version command works. I suspect that there is some missing dependency binding for running updates.
Why is “Ballerina” would be of particular interest to Haiku? The articles suggest it is to do with applications “in the cloud” or big commercial applications rather than hobbyist stuff like what we do. There are so many prototype languages out there I’m curious why this one catches the eye.
Going by vibes, I think it closer in tradition of, say, Plan9 - maybe due to its portrayal as a rival to Go, itself sharing Bell Labs legacy albeit within Google - than to Haiku with its very different C++ heritage. But even that is perhaps tenuous.
Thanks for installing & trying it out. It would take me some time to do that.
I thought Ballerina might be good for Haiku because of its concurrency ability - since Haiku is a multithread capable OS. (For example, its makers say that a Ballerina coded app can run around 20 times faster than if it was coded in Python.) Also, its good for its API-first approach - so maybe it could integrate well with Haiku’s API. Yes, it’s cloud based, but it also says it can make applications - hopefully not just web apps. It has had some promising articles written about it.
But its best feature might be its ability to represent code as a diagram. This would make it easier to learn and debug than other programming languages.
You seem to have picked a random language without actually knowing it nor its underlying concept.
Ballerina is a language created by WSO2, a company focused on open source enterprise integration platforms, to complement their offering.
WSO2 has a rich portfolio of integration solutions such as ESB and API Managament both on premises and SaaS. They created Ballerina where API, in the sense of RESTful APIs, is a first class citizen along with facilities to manipulate json, containerised micro services and event-driven architectures.
The API concept in Ballerina has little to do with an Operating System API, although the two share the same acronym.
Like many of us I consider myself having a lay knowledge of computing generally. But I got to admit that area of expertise might as well be a foreign language - I understood only some of those words.
I’ve been looking at alternative languages, because C & C++ - which Haiku uses - are reportedly difficult to learn and a pain to use. And there’s even more trouble for those 2 languages: To quote a recent news report:
"…the White House Office of the National Cyber Director (ONCD) has called on developers to use “memory-safe programming languages…The report details what it considers to be “unsafe” programming languages, namely C and C++…As more and more of our world becomes digital first, the need for better coding becomes more important. Bad code can be used maliciously to exploit weaknesses.
NSA Suggested Memory-Safe Programming Languages: Rust, Go, C#, Java, Swift, JavaScript, Ruby, Python, Delphi/Object Pascal, Ada.”
This is not to say that Haiku is badly coded, but it will surely need to stay up-to-date with other OSs, and eventually adopt more modern programming languages.
C++ is here to stay for developing the OS itself, I suppose.
Demanding to introduce another language in the OS does not make any sense to me.
C++ and C are the best option to develop an operating system. Redox is developed in Rust which is another option, maybe.
For third-party apps there are other options as long as someone either creates the bindings to the Haiku API or rewrites it in the target language to leverage its intrinsic characteristics.
Python, Rust, C#, Free Pascal, Common Lisp, Swift and Java already exist on Haiku but only Python and C# have working bindings (sort of ). For Rust there’s an attempt to rewrite the API. Swift is still a virgin soil…
Instead of porting another language, pick your language of choice and work on that.
Aren’t these sufficient?
Ballerina is focused mainly on networking, data, integration and concurrency. Not the best candidate for system programming or Haiku apps, IMO.
PS: there’s also a cppfront port now.
Yes, for Haiku the damage is done, and there isn’t really a path to migrate out of C++. This is for various reasons: (relative) simplicity of having to handle only one language, tight coupling of the ABI with the language (meaning it is hard to make C++ work well with another language side by side), a lot of implicit object ownership in Haiku API (we inherit this from BeOS, which pre-dates modern good practices of C++ in that area).
If you are interested in a memory-safe system, I don’t think Haiku can deliver one in any reasonable time. Redox should be a good choice for this. For Haiku, it would need a complete rewrite from the ground up, with quite different APIs that explicitly track memory allocations, for example. Personally, I don’t think now is a great time to do that. We have enough things to finish for our R1 release 
After R1, all options are open. Surely some people will want to maintain R1 and the R1.x system up and running and continue fixing bugs. Maybe it will be interesting to consider a migration to a memory safe language for R2. Maybe it’s already time to start thinking about it and experimenting.
These are great recommendations if you start a new project, but for an existing one, the cost of migrating, of re-training everyone with the new language and so on, may not be worth it.
What could these languages be?
Just to get a general idea.
I might even start practicing in some of those languages now.
Over on the Genode forum we have a similar predicament of the main thing being written in C++ and have discussed a few emerging languages that might be of interest. Anyone for “V”?