Live data from Hacker News

Porting Swift to Haiku

haiku-os.org

41–50 of 53 posts

Re: Porting Swift to Haiku

#41
post #7

I wonder what the plan is for getting swift interop with C++, given that all the Be/Haiku APIs are C++ (IIRC) and swift has no ability to call into C++ code directly.

For now i think you can just wrap it all up in C headers, and implement them in C++, calling the right API.

But giving the way the Swift compiler is itself written in C++ and tied to the LLVM, i bet it will be "easy" for the Swift compiler team to create interoperability between C++ and Swift.

I think their current goal with ABI compability is one step in that direction.. so it will be just a question of Swift understanding C++ mangling in elf/coff/mach-o objects for the link time, and interpret C++ headers using Clang for the compile time.

Given all that, is not hard to predict that Swift will probably have the best interop with C++ code than any other language out there.

Re: Porting Swift to Haiku

#42
post #17
post #7

I wonder what the plan is for getting swift interop with C++, given that all the Be/Haiku APIs are C++ (IIRC) and swift has no ability to call into C++ code directly.

If you want to see one way of doing this, have a look at how D does it: The function mangling and v-table (for single inheritance) are matched between the two languages.

Nitpick: C++, the language, has function name mangling nor v-tables.

Both are implementation-specific (and need not even be identical on a single platform. Early C++ compilers on Windows were incompatible with each other, for example)

Re: Porting Swift to Haiku

#44
post #7

I wonder what the plan is for getting swift interop with C++, given that all the Be/Haiku APIs are C++ (IIRC) and swift has no ability to call into C++ code directly.

For now i think you can just wrap it all up in C headers, and implement them in C++, calling the right API. But giving the way the Swift compiler is itself written in C++ and tied to the LLVM, i bet it will be "easy" for the Swift compiler team to create interoperability between C++ and Swift. I think their current goal with ABI compability is one step in that direction.. so it will be just a question of Swift unders…

The swift compiler being written in C++ has nothing to do with how swift calls into C++ code.

Re: Porting Swift to Haiku

#45

Earlier quoted context omitted.

>> I just feel like this project has lost track of priorities I've been following the development of Haiku (OpenBeOS) on and off since BeOS got discontinued -- for something like 16 years now. While the effort and progress of the Haiku team is commendable, 16 years is a long time to produce an OS, so one might argue that they never had a good grasp of their priorities in the first place. In the 16 years since OpenBeO…

It's kind of off-topic for this thread, but I think there are quite a number of arguments to be made for Haiku's continuing relevancy (although I'm clearly biased :). You're right of course about performance being much less of a big deal these days (Haiku still far outshines even Linux in efficiency, though not in raw speed, mostly due to our lack of GPU acceleration). Instead, the relevancy now mostly has to do with…

All fair points, although I do have one nitpick:

>> the "year of the Linux desktop" that everyone's been hoping will arrive for at least a decade

Everyone might be a little hyperbolic, considering that the majority of people are satisfied with OSX, Windows and/or ChromeOS. And there are plenty of other people who are satisfied with Ubuntu and Mint as their desktops. I would counter that the number of people waiting for the "year of the Linux desktop" is probably a small number.

Re: Porting Swift to Haiku

#46

Earlier quoted context omitted.

It's kind of off-topic for this thread, but I think there are quite a number of arguments to be made for Haiku's continuing relevancy (although I'm clearly biased :). You're right of course about performance being much less of a big deal these days (Haiku still far outshines even Linux in efficiency, though not in raw speed, mostly due to our lack of GPU acceleration). Instead, the relevancy now mostly has to do with…

All fair points, although I do have one nitpick: >> the "year of the Linux desktop" that everyone's been hoping will arrive for at least a decade Everyone might be a little hyperbolic, considering that the majority of people are satisfied with OSX, Windows and/or ChromeOS. And there are plenty of other people who are satisfied with Ubuntu and Mint as their desktops. I would counter that the number of people waiting f…

I meant "everyone" in the sense of "everyone who already uses Linux/BSD/etc." not "everyone" = "general population", sorry for the ambiguity.

And of course one can be satisfied with Ubuntu and Mint as desktops. It's just that when it breaks, you really have to know your way around the plumbing -- which end users don't.

Re: Porting Swift to Haiku

#47
post #32

I get it is not related, but, what are some of the things people do with Haiku? You can browse the web, what else? What other languages are supported, is there Haiku Ruby?

> You can browse the web, what else? There's a decent office suite, Vim, IRC client, etc > What other languages are supported, is there Haiku Ruby? The usual complement of scripting languages (Ruby, Python, Perl, Lua), any JVM language, Go, partially working ports of Haskell and Mercury, Rust (no Cargo port yet), probably some others.

Thank you very much for taking the time to clarify this for me.

Re: Porting Swift to Haiku

#48

Earlier quoted context omitted.

All fair points, although I do have one nitpick: >> the "year of the Linux desktop" that everyone's been hoping will arrive for at least a decade Everyone might be a little hyperbolic, considering that the majority of people are satisfied with OSX, Windows and/or ChromeOS. And there are plenty of other people who are satisfied with Ubuntu and Mint as their desktops. I would counter that the number of people waiting f…

I meant "everyone" in the sense of "everyone who already uses Linux/BSD/etc." not "everyone" = "general population", sorry for the ambiguity. And of course one can be satisfied with Ubuntu and Mint as desktops. It's just that when it breaks, you really have to know your way around the plumbing -- which end users don't.

Even then, for the "everyone who already uses Linux/BSD/etc.", I would posit that most of them are probably using Macs and/or aren't waiting for "The Linux Desktop" to arrive.

For a huge swath of *nix users, Mac OSX accomplished everything they wanted from a "Linux Desktop" outside of being free and open source. That probably leaves a very small number waiting for the Linux Desktop.

FWIW, OSX is also unified, and requires little knowledge of the plumbing for end users.

Re: Porting Swift to Haiku

#49

Earlier quoted context omitted.

>> I just feel like this project has lost track of priorities I've been following the development of Haiku (OpenBeOS) on and off since BeOS got discontinued -- for something like 16 years now. While the effort and progress of the Haiku team is commendable, 16 years is a long time to produce an OS, so one might argue that they never had a good grasp of their priorities in the first place. In the 16 years since OpenBeO…

It's kind of off-topic for this thread, but I think there are quite a number of arguments to be made for Haiku's continuing relevancy (although I'm clearly biased :). You're right of course about performance being much less of a big deal these days (Haiku still far outshines even Linux in efficiency, though not in raw speed, mostly due to our lack of GPU acceleration). Instead, the relevancy now mostly has to do with…

It's somewhat unjust to lump the BSDs in with Linux operating systems there. One of the noticeable things about them in contrast to Linux operating systems is that they do develop the operating system (which is a "kernel" plus a "shell" of applications, of course) as a single coherent whole.

Ironically, you provided an example of this: Lots of things can qualify as an HTTP client. FreeBSD's "fetch" utility and OpenBSD's "ftp" utility are certainly among them. Those are both parts of the operating system, developed by the FreeBSD/OpenBSD developers.

Re: Porting Swift to Haiku

#50
post #49

Earlier quoted context omitted.

It's kind of off-topic for this thread, but I think there are quite a number of arguments to be made for Haiku's continuing relevancy (although I'm clearly biased :). You're right of course about performance being much less of a big deal these days (Haiku still far outshines even Linux in efficiency, though not in raw speed, mostly due to our lack of GPU acceleration). Instead, the relevancy now mostly has to do with…

It's somewhat unjust to lump the BSDs in with Linux operating systems there. One of the noticeable things about them in contrast to Linux operating systems is that they do develop the operating system (which is a "kernel" plus a "shell" of applications, of course) as a single coherent whole. Ironically, you provided an example of this: Lots of things can qualify as an HTTP client. FreeBSD's "fetch" utility and OpenBS…

I suppose I am a bit in error here, yes. The BSDs are indeed more unified than Linux is, anyway, although the unification only extends a few levels up from the kernel. Desktop environments are still mostly developed by other teams (and are usually just ports of Linux ones.)
Post reply on HN