
Porting Swift to Haiku - wesleyhill
https://www.haiku-os.org/blog/return0e/2017-06-22_gsoc_2017_porting_swift_to_haiku_-_week_4_5/
======
quux
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.

~~~
mhh__
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.

~~~
Someone
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)

------
cosinetau
I am really sad

this isn't about writing

swift as a haiku.

~~~
futurix
That will be in Swift 5!

~~~
cosinetau
Hooray!

------
yellowapple
Great to see. I personally don't use Swift (and don't really want to use
Swift), but I do use Haiku, and more language support means more software, so
I'm all for it.

------
tracker1
I know it's blasphemous... but wouldn't mind seeing Haiku as an electron
target platform. But I've thought that would be a good way to go for many
things since first playing with ChromeOS.

------
desireco42
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?

~~~
PeCaN
> 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.

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

------
jlebrech
the bare minimum it needs is an IDE that can be used to code apps for the OS
itself. and after that being able to run all kinds of programming languages.

Personally i'd like to see the latest version of ruby work and postgres.

But also docker support would suffice too.

~~~
girvo
> _IDE that can be used to code apps for the OS itself_

I'm pretty sure Haiku has exactly that already? Pretty sure it did last time I
ran it...

~~~
throwaway91111
Haiku has an editor. Perhaps that's what you're remembering?

------
imron

      The Haiku OS
      Could use a modern language
      Port Swift to Haiku

~~~
PeCaN
To be fair, it does have Rust (but no Cargo port yet).

And Go, if that counts as a “modern” language.

------
bantunes
I just feel like this project has lost track of priorities, or doesn't want to
be a credible alternative OS anymore. As a long time fan of the project - who
cares about Swift? Where's the next release?

~~~
slantyyz
>> 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 OpenBeOS was announced, the world has changed
drastically.

I remember running BeOS on a Pentium II, and it was amazing... at the time. It
did some stuff that Windows and MacOS couldn't easily do performance-wise,
because of its time slicing.

I remember simultaneously playing back four or five videos on BeOS at the same
time without any hiccups, and you could barely do that with two videos on
Windows on the same hardware. Because modern processors are so powerful, even
on phones, _most of the benefits I wanted out of OpenBeOS (Haiku) around 2000
no longer have value today_.

I still follow Haiku's progress because of some BeOS sentimentality, but to
_me_ , it's now a novelty more than anything.

~~~
waddlesplash
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 the unity -- or rather the
lack thereof -- amongst NIX operating systems. While Linux dominates the
server market, the "year of the Linux desktop" that everyone's been hoping
will arrive for at least a decade now hasn't arrived. Sure, there are new
challengers now and again but most of the problems and criticisms of Linux
aren't about the look and feel, but usually fall on a more fundamental level:
"Stuff breaks and then it's impossible to fix." \-- "My audio drivers don't
work and this tutorial to troubleshoot it is incomprehensible to me." \-- "I
took some updates and now Kdenlive doesn't export audio anymore."

Haiku is very different in this respect because its underlying architecture is
the one thing Linux/BSDs are not and never will be: _unified_. The entire
system, kernel to HTTP client to file manager, is developed by one team on one
infrastructure inside one git repository. Which means as a result, you always
know whose fault it is when something breaks (ours), and that when we fix it,
it'll appear in the "nightly" update channel by the next day. It also means
that there's no long series of configuration changes to try when something
doesn't work; almost universally, stuff either works or it doesn't. Really --
there's only one exception to this I can think of (relating to a bug in our
port of FreeBSD's Intel WiFi drivers.)

Linux has been trying for a more unified system both up front (e.g.
elementaryOS) and in back (systemd...), but the more I use it, the less I want
to use it and the more I want to use Haiku.

~~~
JdeBP
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.

~~~
waddlesplash
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.)

