On Tuesday 29. May 2018 11.02.57 William ML Leslie wrote: > On Tue, 29 May 2018, 4:24 pm Nala Ginrut, <[email protected]> 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.
