Current status of language bindings?

I would like to get into programming and make applications, but I’m not so interested in C or C++. Is there anywhere where I can see the status of various language bindings for Haiku or how to get started using them? Most of the information I found is from 3, 5 or 10 years ago. Also, how difficult is it to improve the bindings or create new bindings?

I’m primarily interested in modern languages like Zig, Nelua (or maybe Lua), Beef, Odin, maybe Rust, etc.

There are still not that many bindings.
The only complete and actively maintained BeAPI binding I know is YAB,some sort of Basic which is maintained by the people if I know right.
Another option is Bethon,Python-bindings for the BeAPI but I think it hasn’t been updates for years and I don’t know if it’s complete or still functional.
Most people use C++ to write Haiku apps,I also didn’t want to learn it because I thought it’s too difficult,but now I started learning it anyway because it’s the only thing that currently makes sense if you want to write truly native Haiku apps.

I just don’t think that I would enjoy C++ much even if I were able to learn it. I see how senior developers who have been coding in C++ for decades are still struggling with bugs and debugging the language and the compiler and so on. I want to do more with less code and spend more time on features than hunting down bugs that seemingly could’ve been avoided with a different language.

1 Like

C++ is the best way to write code for Haiku, since that’s the native language for the OS itself.

For Rust, there is a crate for Haiku: haiku - Rust maintained by @nielx


I am a Zig and Rust fan as well. I might experiment with trying to have business logic in Zig which exposes a C API that could be called from Haiku C++ GUI code. Though I know that is not what you are asking for.

At the end of the day the C++ ABI is just not stable enough for other languages to work with (though maybe on Haiku it could be a bit more stable.) So we really need plain C bindings for the Haiku API, which can then be wrapped in other languages. Zig makes this much easier than Rust.

Another harder option is to write native APIs in each language which talk directly to app_server and the media_server, etc, but that is a lot more work, but maybe long term the better option as maybe more idiomatic libraries could be made. Though wrappers around a C API can be idiomatic too.

I think maybe the furthest along of a C binding is:

DarkWyrm started this a long time ago and then stopped working on it. I don’t know the state and don’t know a lot about it beyond that it exists. But it is probably worth looking at.

I have interest in this but I have interest in a lot of things but haven’t had the workspace or time to work on Haiku for a while. Though I hope to finally sort that out in the next few months (famous last words.)


Not really. Itanium C++ ABI is stable and it is available starting from GCC 3 (June, 2001). I made a port of GUI Oberon system to Haiku API by directly using C++ ABI from Oberon. I think that unstable C++ ABI is a myth. Currently only 2 major C++ ABI exists: Intel Itanium and MSVC.


Hello Nipos.

You are with Yab. I do my best to maintain the language.

Regards lorglas

The lack of language support is a bit of a bummer. It looks like I will have to stick to cross-platform libraries for now.

Do you think that Zig/Nelua/Beef/Odin/Rust bindings directly on top of Haiku’s C++ API (no C middleman) would be feasible?

It is definitely possible. The best solution would be making LLVM based code generator from C++ header files.


Some simple demo for x86_64:

#include <stdio.h>
#include <stdint.h>
#include <dlfcn.h>

typedef struct {
	uint8_t unknown[376];
} BApplication;

struct {
	void (*BApplication_Create)(BApplication *self, const char *signature);
	void (*BApplication_Run)(BApplication *self);
} sLibbe;

void Init()
	void *libbeHandle = dlopen("", RTLD_NOW);
	sLibbe.BApplication_Create = dlsym(libbeHandle, "_ZN12BApplicationC1EPKc");
	sLibbe.BApplication_Run = dlsym(libbeHandle, "_ZN12BApplication3RunEv");

void Do()
	BApplication app;
	sLibbe.BApplication_Create(&app, "application/x-vnd.Test-App");

int main()
	return 0;

I believe ocaml has some level of haiku/be api bindings

I’ve done API for ocaml, enough to write a reasonably full featured application. Plagued by bugs, though, honestly - occasional breaks for reasons unknown.

It’s an example of how the C++ ABI is the least of your worries. As mentioned above, you can get by with C bindings, and it’s a fairly simple matter to generate them, to the extent that the API is well characterized. But the difference between C++ and the languages everyone wants to use, goes considerably beyond how you spell entry points. It’s a fair bet that my problem with ocaml is that somewhere in my interface, I’m doing something wrong that breaks the “garbage collection” memory recycling system.

In the end, I think anyone who wants to go there, has to be prepared for a certain amount of struggle. The API interface is never going to be 100% - you’ll have a mountain of BView subclasses, for example, but maybe not the replicant features, because how would that react with your runtime? Maybe the memory layout of the property object is too much of a headache, so the scripting interface is not fully implemented. Maybe the newer stuff like layout has fancy C++ features that make it harder to do the C layer. Etc. And then there’s the mismatch with the runtime that will lead to crashes, weird issues with threads, memory leaks … So the idea that you’re taking the easy road to Haiku programming, has to be examined somewhat critically. It’s more for people who are really dedicated to the “foreign” language in question.

1 Like

I think some of those problems were going to be addressed by the OpenBinder framework that never quite made it to BeOS. Maybe something similar could be used in Haiku? It would still be a lot of work to create it(or to resurrect OpenBinder)

1 Like

Seems like an absurd, developer bottleneck.

I think not, but as usual, people are welcome to step up to the problem. Word of warning, though - by the time you’ve got everything really sorted out, your language will be yesterday’s happening thing.

I think go lang is gonna stick around