Hey. So how did it Go? 
I’m interested in getting Go working on Haiku too, for my own nefarious needs. I had a look at it a while ago but seemed to need to get IIRC 1.5 working, then use that to build the latest version of Go.
How did you get on?
It doesn’t work. I’m currently lost in how Go & Haiku manage system calls and such. I tried to get started with the existing work, but I wasn’t successful. Instead, I started from scratch. Luckily the Go build environment is OS-aware, so if you tried to build for a new OS, it builds for the host OS with support for the host OS with support for the target OS, then rebuilds for the target OS. So for me, it was building a Linux version which understands and would later build for Haiku. My code is at https://github.com/rjzak/go/tree/go1.11.4-haiku.
1 Like
Swift is the best fit!
1 Like
That’s exactly why we dont have 1.5 running. I watched all the changes that were done on 1.4 (with syscalls done “by hand”) and tried to update a clean 1.5 version with them. 1.4+ have changes on the code where they were using some c-files and now code is in go files with go syntax, hence a code conversion has to be done too.
So… unless syscalls are done again in go-format to match the minimal version, probably means no further versions available.
Meh, I’d much prefer getting V8, libuv and Node working… But that’s so much more work!
1 Like
1 Like
Oh that’s very cool. I’ll take a look! Thank you!
Need to apply the steps in a more sane way with the LTS version instead what was the master branch at the time, so it may work upstream or in a not-so-modified and handcrafted version
Go is requiring the syscalls to be in Go. I did look at what was done before, but there isn’t a clear link between a needed syscall in the old C code to the newer Go code, which would mean I could then just copy it.
The old Go port did not do this. Our syscalls aren’t part of the stable ABI unlike in Linux and *BSD, so it would not be a good idea to do this for Haiku (whenever we add a syscall, others may get assigned a different syscall number. Or occasionally we add an extra parameter to an existing syscall).
IIRC the Go port used the same strategy as on Solaris (or another UNIX, I may remember wrong?) to have a thin wrapper calling our C library. That means there is some overhead, but in Haiku the stable ABI interface is at the C library, not the syscall level, so you don’t really have a choice. Maybe after R1 is out we will freeze our syscall interface?
1 Like
That’s just what i said above. I made the syscalls in go up to achieve “something”, but failed when bootstraping the go modules (iirc).
Exactly what happens in most of the calls. I had to read some of the files for Haiku source code values & go port values for most of the things. Also, the ELF format for the final compiled go executable is different from other OS (i mean go’s elf C definitions).
I dont remember that. Maybe i was blinded by the syscall number parts, but i think we just syscalled as much as possible without layers. The biggest issue is having to make the syscall parts (however you do), and tweak all the values of build variable (+haiku), and provide a haiku file.
May be ok to just have one of the existent os and tweak a bit for our needs (bootstrapping more modern versions) and keep the +haiku separation in “latest” version.
On a slightly unrelated note, this would be a perfect issue to cover off at BeGeistert if we do decide to do it in London. We have a bunch of Go programmers in Pivotal Engineering, some of which are based out of London. I’m sure I could offer enough cake/beer to get them to help us out.
2 Likes
Swift has no future beyond the Mac. Just like Objective-C.
Python native API bindings make the most sense.
As much as I dislike Python but I have to agree with you.
“… make the most sense”, out of which alternatives, with what objective in mind?
In my experience with Python native API bindings … kind of complicated for casual use, and kind of limited for serious applications. Python itself sure has some advantages over C++, but it isn’t the ultimate in software engineering either (I lost a lot of enthusiasm for it over the years.) I wouldn’t say Haskell is perfect either, but if I could pick the set of alternatives and the objective, I could make a case that a Haskell native API makes the most sense. Someone else could probably argue that an Objective CAML native API makes the most sense.
We have a Node.js build on Haiku. Bindings for that shouldn’t be too hard. ES6/JavaScript is one of the world’s most popular languages and may open us up to a lot more developers.
2 Likes
I think Swift or Kotlin would make sense. If we were closer to support Mono, C# would make sense.
1 Like
Hi…what is the status of the Node.js build - is it completely working? what version? available for public consumption yet? if so where to get it?
https://discuss.haiku-os.org/t/finished-porting-experimentally-core-node-js-to-haiku/7468/13
Javascript, oh no 
! Say goodbye to speed and efficiency of applications… Say hello to completely insane language semantics…
1 Like
I would definitely take a hard look at swift. I already know C++ very well, but I haven’t had a chance to do much with swift. It would be interesting to give it a shot.