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!
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?
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.
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.
I think Swift or Kotlin would make sense. If we were closer to support Mono, C# would make sense.
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…
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.
Not seeing Haskell nor Curry being used as an API caller here(probably not even a functional language either). Specially when haskell support is not-ready on haiku itself (old GHC), and good luck trying to migrate a current GHC here.
I migrated that to be “ok, could be done if we cut here, put some placeholder here… voilà, node in Haiku”, not an usable version right now. It was 11.0PRE (iirc), and you could get from the thread links itself and build it (hours of compile time?) . I would wait for someone (other person or myself) to port a LTS version in a saner way before using it for … anything.
Also, creating native calls were not that easy, back in mammuts era when I read about that in Node, despite agreeing on popular languages attracting peeps.
V8 execution of javascript isnt slow, it’s all the browser blobs of code that go above what make it go bloatware. I have a discord bot 24/7 running on node and works very well (speed & very low mem usage). regarding language semantics, clearly agree 
Wish we can achieve Kotlin (JVM) and migrate/port/adapt Kotlin Native on Haiku. Regarding C#, and knowing all the LLVM nightmares it would bring, i wouldnt migrate Mono but .NetCore, as that’s the future for now on (and would allow ASP/MVC web development).
I would “master” the language before making an API itself. Dont even dare to create a full official one in Python, despite coding most of the time in it since years (at work / home).
Probably, I don’t know. I just see things like, the only possible number type is floating point, and that it uses run time type inference with type coercion like someone read a python handbook backwards, and then look at the memory footprints of a few electron apps, and think… this is probably not the most efficient way to do things.
Hi,
I see a lot of fighting over which language would be better, and little work done.
Bindings for any language are welcome. Pick your favorite one, start hacking and see where you can get. You will learn about both Haiku and your language 
There is also opportunity for collaboration, trying to share some of the effort between different languages. SWIG may be used, or specifically for Haiku, there is/was a libcharlemagne which also made this possible.
So, you have all the needed resources, now someone has to do the work. No need to argue over which language to pick here, just start hacking and see how far you can get.