Re: Reviewing Hurd-on-L4 (and considering its future?)

[Paul Boddie]

On Tuesday 29. May 2018 11.02.57 William ML Leslie wrote:
> On Tue, 29 May 2018, 4:24 pm Nala Ginrut, <address@hidden> wrote:
> > 
> > Speaking safe languages, are you proposing another language like Rust to
> > replace C? I think it's interesting to write another Hurdish kernel with
> > Rust, but I still don't know if it could be accepted as a side-project of
> > Hurd.
> 
> Rust is one option. But remember that the Hurd is not a kernel, it is
> user-space implementation of functionality that has typically lived in the
> kernel.

This is especially important for us to remember when discussing Hurd-on-L4 as 
opposed to a more general Hurd-NG, as I understand the terminology, with the 
latter potentially bringing up new kernel designs and implementations.

Personally, I'm more interested in the former because it confines the activity 
to something I can actually contemplate pursuing. It is also why I asked about 
opinions of more modern L4 implementations than Pistachio and their potential 
suitability.

> For the sake of both security and ease of development, critical parts could
> be written in rust (or ATS, or Nim), and less critical parts in guile or so.

Just to get things written and to fit in with existing systems, I've been 
writing C and C++ - mostly the latter - to get familiar with L4Re. I guess 
that the language story is pretty similar with Genode. I don't particularly 
like writing C++, but I also don't feel that I should be getting language 
implementations and bindings working on a fairly unfamiliar system before 
doing anything else.

However, there are papers about other languages being used - I recall a thesis 
about Go on L4Re - and some version of Python appears to be available for 
L4Re, although I haven't investigated it yet. L4Re employs Lua for init 
program scripting, and I think Genode employs Nim for this purpose.

> > Anyway, it's using name mangling like C++ which is bad for FFI (foreign
> > function interface) to bind dynamic languages. I ever thought to write a
> > thing like cl-Hurd with Guile.
> 
> We learned a lot from Arne's python bindings. Add language binding to the
> list of priorities that should be higher.

The L4Re developers expose a lot of the APIs to C programs, with perhaps only 
some things being C++-only, and even then I imagine that the reason for any 
limitations is a lack of time for them to go through and provide complete 
coverage. Of course, C++ binding technology for languages like Python has 
existed for many years, thinking of tools like SIP which still manages to do 
that job reliably and dependably.

Paul

P.S. I certainly agree that broad language support is desirable. One Free 
Software project I can immediately think of deliberately disfavoured languages 
other than C++, instead of supporting language binding developers properly, 
only then to "pivot" and support JavaScript as the new cool thing. That pretty 
much told a bunch of existing and potential developers to go and look 
elsewhere for no good reason and discarded momentum that arguably hasn't ever 
been regained.