Haiku Activity & Contract Report, November 2025 (ft. Go) | Haiku Project

Blog
1

This report covers hrev59111 through hrev59187.

The most notable development in November was the introduction of a port of the Go programming language, version 1.18. This is still a few years old (from 2022; the current is Go 1.25), but it’s far newer than the previous Go port to Haiku (1.4 from 2014); and unlike the previous port which was never in the package repositories, this one is now already available there (for x86_64 at least) and can be installed via pkgman.

This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/waddlesplash/2025-12-12-haiku_activity_contract_report_november_2025
24 Likes
2

Very impressive work! Thank you all involved! Amazing how you constantly and relentlessly work on Haiku, great! Thank you very much!

3

Hey! Forgot the first commit of November! with my super duper ultra awesome implementation of fuse_get_session() (to save you a click, I just did return NULL; there and got lucky :smiley: ).

In any case, just mentioning it because that little change, together with the recipe for sqsh-tools, should allow anyone interested in mounting SquashFS files/images to do so in a recent enough nightly install.

Good work, everyone, keep it up!

4 Likes
4

Whoops, so it does! Just added that. (I had to go through the changes a little differently this month because of the new git browser not showing commit dates the same way, or tags at all, so that’s how it slipped through the cracks, I think.)

5

Thanks again for all that commited to the progress again! :+1: Also a warm welcome to the new contributor! Thanks!

6

I noticed the new Go package, and I don’t even use Go! But this is a big step forward. (Too bad the Micro text editor now requires Go 1.19; figures. :face_with_tongue:) Other updates this month also sound good.

1 Like
7

Nice to see Go available in Haiku.

2 Likes
8

Thanks all for this great progress !

9

Very cool, that is a major reliability improvement. I wonder how the situation is with input_server?

Edit: maybe we can even offer to restart without custom decorator/control look after N crashes? hmm.

10

input_server itself already support restarting. The problem is some kernel input device drivers that do non-interruptible blocking.

11

Wouldn’t that mean, we could run 2 app_servers for 2 displays and detach an app from one and attach to the other?

12

No. It is only about fail safety. It allow to restart app_server if it crashed, keeping GUI applications running. Only one app_server can run at the same time.

13

That sounds like a major, major development. I recall when Tracker and Deskbar could bring the system down, now they can crash, they restart and it is just a minor annoyance. If the same is true of app_server we are now going to see some serious uptimes. Give @waddlesplash a raise!

And since Terminal itself is a GUI application, it indirectly even gives CLI a little reliablity boost.

14

Note that app_server restart ability was implemented long time ago, but it was not enabled by default because of being incomplete and unstable. Me (implementing reference counting for imported areas) and waddlespash (app_server restart logic) added missing bits to make it actually functional. It is still not 100% perfect and applications may lost some state after app_server restart.

11 Likes
15

Nice work everyone, thank you.

16

Syncthing on Haiku has never been closer!