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.